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ABSTRACT 



This research focuses on the principles upon which 
models have been, and may be, constructed for estimating 
cost and effort in software development projects, A defini- 
tion of and factors influencing software engineering 
economics is presented. The major phases and activities of 
the software lifecycle are described. Effort, rime and cosr 
estimarion is analyzed. A presence tion is rhen given of 
some widely used models for estimating cosc and effort. 
Critical factors which muse be considered when constructing 
a model for escimatinq cosr and effort in sofeware develop- 
ment pre jeers are then presented. We summarize by citing 
areas rhat require more artenrion if cosr and efforr esri- 
mares are to be further improved. 
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I. INT80D DCT I0N 



A. BACKGROUND 



The history of software engineering is replete wirh 
tales of oroiects that have never been completed or have 
reached completion only after numerous cost overruns and 
well beyond the originally scheduled operational date. As 
the problems with software engineering became increasingly 
apparent, researchers directed their attention to finding 
ways to more accurately predict the cost, effort and time 
that a software development project would require. 
Attention has been devoted to det 
as early as possible in the project, 
developed to provide single esti'r 
ments. hodels gradually evolve 
various stages of the lifecvcle. 



min ing 


sound estimates 


Ini 


tially models were 


9S in 


specific environ- 


nha n 


could be used at 


Models 


are now available 


t 


lifecycle and can 



be transported to different environments. 



B. PROBLEM 

The problem to be addressed in this study is to find 
those influences that affect estimates of cost and effort in 
a software development environment. The characteristics 
that are identified will not necessarily apply to all envi- 
ronments but must be evaluated to determine whether they are 
contributors to cost, effort and scheduling in a particular 
sit ua tion. 



9 



C. GENERAL PROCEDURE 



The procedure that has been used was to research litera- 
ture concerning cost and efforr estimations in software 
develcpmenr projects. Information was gathered concerning 
some of the most widely used and successful estimating 
models. We gathered from this research numerous criteria 
that must be considered by the estimator before implementing 
any model that estimates cost and effort in a software 
development oroject. We also noted influences on software 

develcpment projects that have not yet been adequately 
addressed in cost and effort estimating efforts. 

D. ORGANIZATION 

Chanter II develops a definition of software engineering 
economics and presents the major influences on software 



pro jects . 
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is then examined 
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Ch 


apter IV examines 



factors important in effort, time and cost estimation. 
Chapter V presents a number cf popular models that have been 
and currently are in use in estimating cost and effort. Key 
factors affecting software cost and effort estimation are 
then presented by the authors of this research paper in hope 
that these will be addressed in developing a superior cost 
ana effort estimating model. 
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II. ONDERSTiMDING SOFTWARE EHGINESRING ECONOMICS 



A. A DEFINITION OF SOFTWARE ENGINEERING ECONOMICS 

The term software engineering has been used extensively 
throughou-c literature to refer to the various stages of 
software development and maintenance. Software now commands 
the maicr part of any budaet for a computer system. In the 
mid 1 950's, 857 : of a computer project's budget was devoted 

to hardware with the remaining given to software. 

Today, these figures are reversed. [Ref. 1; p. 41] The 
refinements and advances in hardware combined with the ever 
decreasing costs of its production have turned focus on 
software and its ability to exploit the system’s innate 

potential. The financial prominance of software in any 

computer system demands that whenever we speax of software 
engineering, we consider the economic impact of cur task. 
Hence, the term software engineering economics will he used 
in this research paper to refer to the development and 

maintenance of software. 

That we are only now beginning to clearly understand the 
complexity of the software issue can be seen from the 
numerous failed attempts to forecast the cost and effort of 
software development projects. Disastrous software develop- 
ment projects have motivated the development of numerous 
cost and effort estimating models that have met with varying 
degrees of success in accurately predicting the course of a 
software development effort. Successful models have been 
used as foundations upon which even more accurate models 
have been developed. The majority of models that are avail- 
able to estimate cost and effort were developed by private 
companies to be used in their own working environment. 
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These models when applied to other environments are unpre- 
dictable and therefore of questionable valu<= [Ref. 2; p. 
116]. We will examine the most prominent of the numerous 
cost estimating models and evaluate their characteristics 
and applicability. We will seek to uncover the remaining 
problems that currently available cost and effort estimating 
models inadequately address or completely ignore. 

We begin by develooing a definition of software engi- 
neering economics through reviewing definitions of the term 
software engineering as offered by a number of prominent 
individuals in the computer industry. The most comprehen- 
sive work on software engineering economics is a recently 
published text of the same title by Barry Boehm. Boehm 
defines software engineering as "...the application of 
science and mathematics by which the capabilities of 
computer equipment are made useful to man via computer 
programs, procedures, and associated documentation" [Ref. 3: 
p. 16]. Peters and Tripp at the 3rd International 
Conference on Software Engineering define software engi- 
neering by identifying the concepts and their relationships 
that surface in a study of software engineering [Ref. 4: p. 

63]. Remus of IBM's Santa Teresa Laboratory defines soft- 
ware engineering as "...the science of implementing given 
functional and performance requirements in a program with 
optimum quality, at minimum cost, while meeting committed 
schedules" [Ref. 5: p. 267]. Kerola and Freeman at the 5th 
International Conference on Software Engineering present 
software engineering as "...the application of methods, 
tools and techniques to actions in a reliable and predict- 
able manner or (a) set of stated, technical, economic and 
social goals for a software artifact" [Ref. 6: p. 91]. We 
especially note the reference to the social aspects of soft- 
ware engineering. If the human aspects of software 
engineering are not taken into account as concerning both 
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the developers and the users, the software product will not 
realize its full potential. We define the term software 
engineerinq economics as the art and science of utilizing 
analytical techniques, managerial principles and common 
sense to affectively and efficiently conclude the develop- 
ment and maintenance of software at minimal cost. 

B. INFLUEHCES ON SOFTWARE ENGINEERING ECONOHICS 

1 . Si^e 

A number of methods have been used to estimate the 
size of software development projects. Early estimates of 
project size are not likely to be very accurate as the exact 
nature and scope of the project are not conclusively known. 
Putnam and Fitzsimmons recommend estimating the size of a 
software development project using the laws of statistics 
and probability and including the standard deviation for 
each estimate. Early estimates are based on oast experience 
and the available information the developers have about the 
pro ject. 

As more and more attention is being given to the 
early determination of the design and specificat ions of a 
project, estimators have an increasingly large amount of 
information to use. The increased effort being given to the 
front-end development of a project will substantially 
decrease the final cost and effort expended on a project 
because of better project preparation. Structural decompo- 
sition is used to more clearly understand and closely 
estimate the size of a project by understanding and esti- 
mating the size of each segment of the project. During the 
development process, iterations of size estimations continue 
to improve the certainty of the size of the project. 
Accurately estimating size is the major obstacle in esti- 
mating the cost and effort required in software development 
pro jects . 
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The following criteria have been used extensively in 
estimating the size of a software project: lines of source 

code and executable instructions . A fairly recent develop- 
ment in complexity estimation developed by Halstead that 
will be discussed later asserts that size is a function of 
the vocabulary of a program . The vocabulary of the program 
is the sum of the operators and operands used. According to 
the author, lines of code, length (sum of the number of 
times operators and operands are used) and vocabulary are 
all valid measures of program size. The problem with 

Halstead's and other techniques of size measuring is that 
they are after the fact tools, i.e. , the developed software 
must be available to use them. Although refinements 
continue to be made in the area of estimating program size, 
no absolute method has yet been developed that will conclu- 
sively estimate size early on. 

As the size of a project increases, other factors 
become mere prominent as cost drivers. Complexity, inter- 
faces and the number cf people involved become the primary 
cost drivers. As the size of the project increases, the 
number of people involved in the project increases and 
significant new problems are created. Brocks learned from 
his experience with the IBM OS/360 project that men and 
months are not interchangeable. Using man-months to measure 
the size of a project is dangerous since men and months are 
only interchangeable in an environment where a job can be 
perfectly partitioned among workers and workers separated 
from each other to preclude communication. In reality, 
training and communication take up a significant amount of 
time in increasingly large projects. [ Sef . 7; pp. 13-26] 

And although time consuming, communication is essential for 
a successful project. Esterling's research also showed that 
project completion time can be improved upon only up to a 
certain point by adding personnel. Added personnel eventu- 
ally serve only to delay the project. [Ref. 8: p. 168] 
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2 . 



Com plex ity 



Software engineers use complexity to denote treat- 
ability, maintainability, readability and/or 

comprehensibility of a program [Ref. 9: p. 317]. Complexity 
plays an important part in two phases of a software life- 
cycle: development and maintenance. The complexity of a 

program will directly influence the cost and effort in 
testing and debugging and in correcting bugs that subse- 
quently surface from use. The difficulty of modifying a 
program due to changing requirements will also be directly 
related to the complexity of a program. Complexity measures 
have proven difficult to objectify in project evaluations. 
The main problem with both size and complexity measures is 
that they are done after the fact, i. e., after the code has 
been written. A complexity measure will be judged on its 
ability to predict programmer performance. Much research in 
the complexity area implies that programmer performance can 
be predicted from the source code of a program. 

The question being asked today is which factors of 
the many researched in programs best capture program 
complexity. Two other factors have shown to influence 
program complexity: the programmer and the programming 

task. Significant individual differences have been found in 
programmer performance. "The important point here is not 
that individual differences among programmers exist, but 
that the v ariabilit y is so large that experimental results 
may depend, mors c-n individual differences than on experimen- 
tally induced differences" [Ref. 9: p. 317]. What might be 
ver-y difficult for o-ne programmer may be easy for another 
thus nullifying the value of th.at predictor. Programmer 
performance must be based on a combination of program 
related complexity measures, programmer traits and 
programmer tasks. 
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One of The newest approaches to measuring complexity 
has teen presented by Halstead in which lines of code are 
broken down inro operators and operands. Three advantages 
of this approach are: 



1. An exDlainable methodology for calibrating a 
measurement instrument. 

2. A more nearly universal measure, since the 
apcroach is consistent across the boundarres of 
programming languages. 

3. The ability to relate some of the effects of 
programming stvle to measured auantities. 

fEeL 10; p, 3731 

The rules for this method seem to combine lines of code, 
decision nodes and operation codes, variables and punctua- 
tion. The emphasis given to each area is questionable but 
at least they are all included. [Ref. 10: p. 374] 

Halstead defines length as a function of sum of 
operator usaae and operand usage. Length can be estimated 
from vocabulary with reasonable certainty according to 
Halstead. Volume is a function of vocabulary and length. 
Lines of code, length and volume are equally valid as rela- 
tive measures of program size. Program size measured in 
lines cf code, length or volume is a function of vocabulary. 

Halstead also presents an equation for measuring 
difficulty. Difficulty is defined as the measure of ease of 
reading and ease of writing a program. Difficulty affects 
the effort needed to code an algorithm, to inspect and 
review it and to evaluate it later when changes need to be 
made to it. Various levels of difficulty are experienced 
due to the skill level of the programmer, poor program 
structure or the lack cf experience with a language and 
possibly the complexity of the algorithm. [Ref. 10: p. 381] 
Halstead identifies six code impurities that if eliminated 
reduce the level of complexity of the program. They are as 
follows: 
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1. Complementary Operations: unreduced expressions 

2. Ambiguous Operands : the same variable means 

different things 

3. Synonymous Operands: giiring the same value to more 

than one variable name 

4. Ccmmon Subexpressions: subexpressions used more than 

once in a program. The subexpression should be given 
a unigue variable name 

5. Unwarranted Assignments: assignment of a variable to 

a subexpression even 'hough the variable is used only 
once in the program 

6. Unfactored Expressions: easy to understand but at 

times hard to follow in coding, [Ref, 10: pp, 

382-383] 

Halstead's measures are attractive in that they are easy to 
aut omat s. 

Another measure of complexity that has achieved seme 
measure of universal acce ptance is that presented by T. 
McCabe. In McCabe's cyclomatic complexity measure, all the 
decision points in the Procedure Division of a program are 
counted, those for each paragraph and section are summed, 
and those for the entire program are summed. A paragraph is 
assumed to be the size of a module and assigned a complexity 
value of one to start. When a complex conditional statement 
is encountered, each simple conditional expression is 
assigned a value of one. Research to correlate Halstead's 
and McCabe's measures with programming effort have shown the 
following (especially respecting Halstead's work): 

1. Reasonable correlation exists between the measures 
and programming effort. 

2. A comparable correlation exists between the measures 
and the number of instructions in the programs, 

3. Number of instructions seem to be as good an indi- 
cator of software development effort reguired for 
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large programs (over 1000 DSI (delivered source 
instructions)) as the Halstaad and McCabe measures. 
The measures, however, correlate better than DSI with the 
amount of terminal time required to program small programs. 
[Ref. 3: p. 481 ] 

The weaknesses of the measures lie in their not 
accounting for such factors as personnel experience, hard- 
ware constraints, managerial factors and the use of tools 
and modern programming practices. The user must also become 
accustomed to using the measures and, as already stated, the 
measures involve a knowledge of program characteristics that 
are not learned until the program is writ-^.en, 

3 • Int erferenc e 

Interference factors include the total of all 
disturbances that affect programmers* productivity. 
Administrative or ncn-direct work includes such activities 
as budget oreparation, union meetings, and stvatus report 
submissions. Social inte ractions are a second source of 
time loss. Thirdly, interference includes the time consumed 
in regaining a creative thcught pattern after interruption. 
Creative people are subject to environmental influences on 
their ability to evolve a new program. A fourth source of 
interference is the time spent coordinating with other 
programmers while developing a program. A fifth source of 
interference is the number of miscellaneous interruptions 
that result from passing social interactions, trips to the 
head, etc. [Ref. 8: pp. 164-166 ] 

Interccmmunication is essential to any project. To 
minimize intercommunication, as few people as possible 
should be involved in a large project if completion tim-e is 
important (as inevitably it is) . Brooks suggests the use of 
programmer teams to improve upon the completion time of a 
project. The task is divided up into a number of segments 
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and each reain operates on its own as far as possible to 
complete a segment of the project. 3sterling's research 
showed that programmer productivity can be increased in an 
interrupt free environment. Interference factors command a 
large portion of the programmer's time and must be addressed 
in any estimation of cost and effort. 

4 . Cost 



Cost has played a major role in d=^v=lcping software 
engineering economics due to the many cost overruns on soft- 
ware engineering projects. Cost overruns have become the 
driving factor in efforts to develop software cost and 
effort estimating technigues. Escalating personnel costs 
have driven companies to new awareness of software develop- 
ment projects. A severe shortage of software engineers 
presently exists along with greater shortages in the number 
of senior software engineers whose competence an i exoertise 
in guiding a project can often result in an outstanding 
product as opposed to a mediocre product. The job market 
for software engineers is good and the cost of hirina 
programmers and analysts continues to grow in dominance in 
the overall cost picture. Estimates indicate that the cost 
per man-year of a software engineer will be 100,000 dollars 
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discussed, adding programmers to accelerate a software 
development project will only be beneficial up to a certain 
point beyond which dimxnishing returns will be realized. 
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Initial development cost may be expensive for a 
proiecT tut experience indicates than for every five dollars 
spent on initial development, between seven and twenty 
dollars will be spent on maintenance. With this skyrock- 
eting picture of costs throughout the lifecycle of a 
project, estimates for a software development project and 
the subsequent plans for and implementation of a software 
development project must be carefully managed. Since so 
much of costs will involve personnel, software development 
environments will be increasingly looked to for the best 
ways to exploit the potential of software engineers. 
[Ref. 11; p. 227] 

Recent findinas indicate that contrary to intuitive 
feelings about the matter, the total cost of a project will 
decrease along with development time when overtime is paid 
to workers. If time and a half is paid, the overall cost 
decreases; if double time is paid, the overall cost remains 
constant. Indirect costs will have a separata impact cn . 
overtime work since they do not vary over time. If the 
indirec-^ costs are high, savings can be realized by hiring 
consultants and by-tli e-hour people. [Ref. 8: p. 170] 

Thus we see that the primary driver of the cost of a 
software development project is the personnel involved. 
Personnel must be carefully selected for a particular soft- 
ware development project. As will be discussed later, past 
experience of the programmer is of considerable importance. 
After personnel are selected for a development project, the 
management process implemented will determine how fully 
their collective potential is exploited. 

5 . Qua lity 

The quality desired in a given software product will 
directly influence the cost and effort devoted to the 
project. Quality will generally vary according to the 
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nature of the project. Software developed for a manned 
lunar flight will cf necessity be of far greater quality 
than that to support standard business applications. 

Bemus defines quality as '‘...the number of program 
defects normalized by size over time" [Ref. 5: p. 268], We 
find this to be a useful, working definition cf quality. 
Quality cf a software prod uct can be improved by increased 
attention given to the fronn-end design process with 
emphasis on modularization. Jlodular ization or dividing the 

project inro small segments chat are more intelligible 
enables the programmer ro more easily undersnand the objec- 
tive of a task assigned. A better understood assignment 
will lead to a better product. 

Programming environment has a significant impact on 
quality. The ability of the programmers to work in an envi- 
ronment conducive to and supportive of creative thought will 
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p . 226 ]. 



Very cheap, unwarranted, unsupported software will appear on 
the market and be available to the consumer. Inexpensive, 
mass marketed, supported software is not a practical possi- 
bility fcr the future. Four types of software products will 
be available in the future: 



1. Quality products requiring no supoort and known 
to be correct and to function predictably and 
reliably 

2. Quality products that are sold to customers 
willing to pay the support costs 

3. Custom-made products, developed fcr a specific 
user's needs 

4. The others. (Ref. 11: p. 227] 
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Prices for type 1 products will be high and vary according 
to market demand. Type 2 products will be priced consider- 
ably higher than type 1 products. Type 3 products will be 

the highest priced of all software. Type 4 products will be 
moderately priced for mass consumption. Especially sophis- 
ticated software will be sold along wirh associated hardware 
in whan will be a turnkey system. 

6 . Sc h edul ing 

Scheduling is impcrranr in software develcpmer.n 
proiecTS so as to avoid slow down in a program due to -he 
lack of coordination among inn eraependent segments of the 
project. Scheduling shows where in rime all important 
project events rake place. The schedule should include 

milesxones, reviews, key meetings, audits, documenration 
releases and product delivery dares. 

Scheduling is also impcrranr for markerin'i an n sale- 
pur pcses. A product must be available ar the rims when rhe 
markering personnel have premised ir. The botrom line for 
any organization is customer satisfaction and hence profit. 

Project management differs from production manage- 
ment in the nature of the task. Production management 
involves the performance of a repetitive job. Project 

management is much more difficult in that the job to be 
performed and the results of the effort are not clearly 
understood at the outset and are unique for the most part. 
The following characteristics apply to all projects in 
varying degrees; 

1. The project itself will last for weeks, months or 

even years. During this time, many changes may occur 
in the project which may affect cost, technology and 
resources. 

2. The project is usually complex involving many inter- 
related activities that must be monitored. 



22 



3. Projects are expected to be completed on time vith 
any delays costing the developers into thousands of 
dollars per day of delay. Not only is money lost but 
also much ill will may be created from overdue 
projects. 

4, Projects often are sequential in nature with the 
start of one project dependent on the completion of 
another. [Ref. 12: p. 273] 

As a resul- of rhe nature of projects, planning, 
control and coordination of projects is a complicated task 
that requires close attention. Until recently, no formal, 
generally applicable method was available to manage the 
progress of projects. Two methods are now available that 
have proven to be very useful in project management; PERT 
(Program Evaluation and Review Technique) and C?M (Critical 
Path Method) . 

Two differences exist between PERT and CPM. The 
first involves estimating activity durations. An activity 
is an effort that consumes resources and a certain amount of 
time. PERT uses the weighted average of three estimates in 
order to arrive at an expected completion time based on a 
probability distribution of completion times. Because cf 
this, PERT is looked upon as a probabilistic tool. CPM is a 
deterministic tool, i. e. , only one estimate is made for 
duration of an activity. The second difference between the 
two methods is that CPM can give an estimate of costs as 
well as completion time for a project. PERT is fundamen- 
tally a tool to plan and control time; CPM is a tool that 
can be used to plan and control both time and cost of a 
pro ject. 

PERT and CPM attempt to answer the following 
questions: 
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1 



3. 

4. 

5. 



Which activities are critical? That is, which 
must be completed cn time to keep the project on 
schedule? 



Which activities are noncritical? 



How much flexibility does management 
executing the noncritacal activities? 

What is the earliest expected comoletion 
the project? 

What is the best way to handle delays 
detected during execution of the 
[Ref. 12: pp. 274-275] 



have in 

date for 

t h d d T -r 
project? 



In addition, PIRT answers the following questions: 



1. What is the chance of completing a project by a 
desired dare? 

2. For how long should' a project be planned so rhah 
a given probabilitv of completion is a’^rained? 

TRef. 12: pp. 274-275] 



C?M answers the following addirional questions: 



1. What i? ■ rhe leasr-cosr wav to expedire “he 
complerion or a prcjecr? 

2. Whar is rhe shortest possible rime for a project 
to be compiered? [Ref. 12: pp. 274-275] 

?5ET and CPM provide numerous advantages for the 
project manager. The re guiremenrs of the merhods force 
managers to plan ahead in detail ro determine whar has to be 
done to meet project objectives on schedule. Definire deci- 
sions musr be made regarding execution rimes and completion 
times for activities in the projecr. The tools of CPM and 
PERT provide for improved communication among departments in 
the organization and between the developer and clients. The 
devices allow for identifying critical activities in rhe 
project and thus close attention can be given to these 
phases. Since critical activities are most likely to be 
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pozen~ial problem areas, rhess difficulties can be spotted, 
early and adequately planned for. 

Resources are more easily managed using PEST and 
CPM. Once bottlenecks and problems are identified in the 
project, resources can be more easily moved around to 
correct difficulties. Deviations from schedules are more 
easily identified and accommodated. , Since PERT and CP?1 
provide an overall picture of the project, the tools can be 
used easily to present the project to lower levels of 
management. PERT and CPh are easily adapted to computers. 



Alternate ways of executing projects can be evaluated using 
PERT and CPJ1. PERT provides the probability of completing a 
project cn schedule while CPU allows management to evaluate 
the costs of rushing activities. dany scheduling problems 
can be avoided through close adherence to management tools 



like PERT and CPM. 



Again we observe that attention to the front-end 
development of a project will add immeasurably to its smooth 
accomplishment. The ability *o adhere to a schedule will 
additionally contribute to a project's success as the 
employees will realize personal graoif icat ion as milestones 
are met. Improved motivation will mean an improved product. 

"7 • Past Expe ri en ce 

Past experience plays a significant role in software 
development projects. Companies that have past experience 
in large jobs will tend to overestimate a job and manage the 
job as a large job. Companies with experience in small jobs 
will tend to underestimate a job and manage it as a small 
job. This entire concept has been neglected in each cost 
and effort estimating model reviewed by these researchers, 
CRef. 13: p. 43] 
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Research has found that experience is important if 
the experience that a programmer has is related to the 
current project. Merely programming for a number of years 
will not mean that someone is a good programmer, only that 
he has been programming for a number of years. He may have 
been making the same mistakes and using the same procedures 
during those years. So rhe developmental Datnern of the 
individual programmer and analyst must be examined in order 
no ascertain the maturity of the individual. Programme- 
productivity varies greatly on the same task, some research 
reporting variation of 5:1 while other research has found 
variation up to 20:1. Literature on programmers' experience 
will be addressed again in another segment of this paper. 

3 • ISols 

Software tools have become increasingly a topic of 
research in this decade as software has become so dominant a 
fac-*-or in the development of computer systems. The ergo- 
nomics of software engineering has been described as "...the 
discipline of analyzing and understanding the requirements 
for quality software engineering tools, and of translating 
this understanding into innovative tool design" [Ref. 11: p. 
223 ]. 

Ergonomics deals with the mutual adjustment of man 
and machine. Man has done most of the adjusting as of this 
time and machines now must adjust to human needs. This 
evolution has come about due to the increased costs of 
hiring and supporting programmers. Man initially exerted 
all efforts to exploit computer capabilities; now, computers 
must evolve to exploit human potential. The easier software 
development tools are to use and the more affective they are 
in assisting the programmer to produce his product the more 
efficient will be the entire development program. 
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The tools used during the production process can be 
divided into a number of groups. 

1. The design language should be general enough to 
permit a description in general terms and specific 
enough to be unambiguous. Analyzers assist in 
finding obvious problems and automate some intercon- 
nection cross references. Tools such as the Problem 
statement Language/Problem Statemenr Analyzer are 
comourer -aided s~ructured documentation and analysis 
techniques that aid in developing the requirements 
and specifications for a program and in the formula- 
tion of documentation as the project proceeds. 

2. Editors and on-line document handling facilities 
allow machine use f cr writing, producing and main- 
taining specifications and user publications. 

3. Cede library facilities improve testing and integra- 
ticn of fixes for code errors. 

4. A data dictionary* system, a software system used to 
record, store and process information about all cf a 
firm's significant data entities and related data 
processing functions, provides the following bene- 
fits : 

a) Security and access control for data base environ- 
ments 

b) Standardization of data elements 

c) Identifies redundancies in the data base 

d) Automatic documentation with current information 

e) Improved transportability between computing envi- 
ronments 

f) Assists auditing [Ref. 14] 

g) Interactive code facilitates program development 
allowing each programmer to use a terminal in his 
work 



27 



h) T=st; =iiaulators allow simulation of complicated 
hardware configurations 

i) Test control and test case libraries facilitate 
testing procedures 

j) Service data bases provide solutions to errors 
found that are not yet corrected for public usage. 
[Ref. 5: pp. 273-274] 

Software Development Environment (SDE) is the name 
now used to describe the tools available *c programmers to 
develop a software product and to maintain it. SDE's can be 
as simple as a mixture of assorted tools with little direct 
relation to one another, or as sophisicated as a particular 
development methodology using tools or software utilities 
that are highly integrated and non-r epeti*ious. [Ref, 15: 
p. 20] SDE is a recently developed concept. 

It aptears the software development environment should 
be adaotabie, user -centered, 'suggestive^ heloful and 
supportive, not imposing. xhe tools of toxe environment 
should be portable, methodoloay independent, catalogued 
with respect to assumed user scohistication and they 
should have a specific ourpcse. Einally, the environ- 
ment should support large-scale software production and 
provide a consrstent interface through the entire soft- 
ware life cycle. [Ref. 15: p, 21] 

SDE should provide tools that are integrated and user 
friendly. User friendly characteristics should include such 
things as human interfaces other than text, such as menu 
selection capability, graphics and possibly voice recogni- 
tion. Kot much concern has been shown up to now as to the 
cost of implementing such environments or the cost of 
sustaining such environments [Ref. 15: p. 21]. 

Common potential benefits to be derived from the use 
of SDE include improved software quality, reduced cost of 
software, improved programmer productivity, and mors manage- 
ment visibility. The prevalent feeling is that the use of 
software tools and the SDE is good but as of now no experi- 
mental data exists to corroborate these feelings. 
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Th€ cost of SDE has not been closely studied as the 
environments have been developed to support large systems 
and these systems are usually used by large organizations 
that have substantial resources. Host of the effort is 
directed toward supporting the development phase and not the 
maintenance phase. Companies feel that the development cost 
will be shortened and therefore support the SDS. Not much 
attention is paid to the maintenance pJiase as maintenance is 
considered a source of income for the ccmpanias. [3ef. 15: 
p. 24] 

We believe that little attention has been given to 
estimating maintenance costs for the same reason: mainte- 

nance is seen as a source of revenue. The SDS is mads up of 
a number of components. The software development tools and 
in some cases an implicit set of operating procedures are 
generally understood to be part of the SDE. The SDE also 
includes the organization that is supporting ths environment 
and the integration of the SDE with the corporation as a 
whole. An SDE integrated with the corporation as a whole is 
imoortant for the proper functioning and utilization of th'=‘ 
environment. 

An automated software development environment 
requires sophisicated software support for complex directo- 
ries of files, a sophisicated database management system and 
a standard interactive capability. These capabilities 
require considerable hardware support. 

SDE has had a stated goal of reducing the time to 
develop software. Studies done by Boehm indicate that the 

development time is not reduced but that the time spent in 
development is shifted from writing source code and debug- 
ging to developing the requirements and specifications. 
[Ref. 16] The major problem with the concept of a software 
development environment is getting companies to allocate 
necessary funds to its development and support. Hardware, 
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personnel and training must be provided to implement a soft- 
ware development env ironme nr and to maintain its smooth 
operation in the company. 

9. Hanaqement Polic ies 

Management by Objectives (HBO) is quite compatible 
with using PERT and CPM and scheduling methods. "MBO refers 
to a formal, or moderately formal, set of procedures that 
begins with goal setting and continues through performance 
review” (Ref- 17: p. 144], M BO is a participative process 
that involves communication among managers and staff members 
at all levels. Established links of communication facili- 
tate the planning and control of a project, M30 assumes 
that workers are motivated to perform their jobs and want to 
do as good a job as possible. This view of human behavior, 
called Theory Y, is opposed to Theory X, a view that holds 
workers to be not very reliable and only interested in work 
as a means of survival. People will avoid work whenever 
possible according tc Theory X. 

Programmers are known tc be highly motivated indivi- 
duals who want to create as good a product as pcssible. 
They generally are not too interested in other non- 
scientific people and are mostly concerned about exploiting 
the fullest potential of the computer. A sharp program 
manager will recognize the needs of his programmers, meet 
those needs to allow the programmers tc produce their best 
product, and insure a cooperative climate exists among 
programmers and programming teams and groups. The critical 
role of a program manager will be more closely addressed 
later in the research. 

MBO involves primarily the est ablishment of goals 
through a joint effort of management and subordinates. 
Objective measures of performance are arrived at, i.e., 
lines of source code generated. Performance reviews and 
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regular periodic reviews are made. A primary purpose of MBO 
is to achieve efficient operation of an organization through 
the efficient operation and coordination of its parts. It 
has great value in performance planning and appraisal. 
Managers in the organization are encouraged to work wirh 
personnel above and below them in an effort no achieve the 
besr product possible. When problems arise, the team works 
together to solve them rather than to seek someone to hang. 
Since programmers are creative people, progressive manage- 
ment policies like MBO emphasizing the goals of 
self-actualization are encouraged. 

10. "T he Projec t Manage r 

Software development projects are often large scale 
projects requiring the highest coordination. The qualities 
that the Federal Government seeks in its program managers 
are herein presented for their overall application to any 
large scale, software development project. Oftentimes, 
government acquisition is the driver behind a software 
development project. The characteristics ci the project 

manager who guides a software development project to its 
completion will be critical fcr the success of the project. 
Managing an acquisition program for a large scale, govern- 
ment purchase is a demanding task and requires an individual 
of unique skills and personal character traits. ’’The accom- 
plishment of this objective requires the successful 
integration of people, financial and material resour ces .. .in 
one word — Management" [Ref. 18; p. 8]. "A program manager 
is expected to have an in-depth technical understanding cf 
many areas, to plan, organize, and control with the preci- 
sion cf a military ca nrpa igner , to integrate ideas and write 
•Like a journa.list , ’ and to build and motivate a team of 
managers he may have never met before or work with again" 
[Ref. 19: p. 6]. The responsibility fcr the success or 
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the hands of the 



failure of the acquisition program lies in 
program manager. The job must be done efficiently, within 
the budget and on time. The success of rhe program will be 
a direct reflection on how well the team has been motivated 
to achieve its goal. 

Even if we know the proper way to build and motivate 
a project team, more importantly we must find a program 
manager who can successfully implement this knowledge. Xcst 
imoorrantly, a orogram manager should be an individual wirh 
a positive attitude and keen insighr into human nature. 
Successful projects emerge from people who believe that the 
job can be done regardless of the obstacles. If the program 
manager is a positive thinker, he will foster this artitude 
on his ream. 

An achieving program manager will demand oursrandina 
results. Outstanding effort is admirable but if the product 
is not delivered as advertised, the effort is empty. If 
production has been taking an inordinate amount of time on 
the Dart of certain individuals, personnel reassignments 
should be considered. A program manager should be one who 
remains above interteam squabbles and criticism and be the 
individual who puts such destructive forces to rest. He 
should he an individual who is bound by his work, keeps his 
promises and thereby generates a feeling of confidence and 
certainty within team members. [Ref. 20] 

An effective manager •*. ..must have skill in communi- 
cations, which spans such areas as the ability to axpress 
ideas clearly, the ability to lead discussions and arbitrate 
differences, the ability to ask the kind of questions that 
stimulate and encourage creative thinking and problem 

solving. He must also master the skill of listening so 

that he understands what is said and what lies behind the 
words** [Ref. 21; p. 15]. 
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A recer.t study indicated rhar employees view communica- 
tions with supervisors as the most satisfying and 
important relationships in the working environment, but 
least able to establish. In another study conducted at 
Loycla University. essential attributes of a good 
manager were comoiled. It was found most important that 
managers listen well. Since attentive listening is the 
b-est way to stay in touch with everything that is 
happening, such managers are well informed. Good 
listening, in addition to keeping manaaars well 
informed, promotes good human relations. [Ref. 22: pp. 
4^-6 ] 



A program manager must feel secure within himself. 
He must bs able to function with the knowledge that he will 
be held personally accountable for the success or failure of 
the acguisiticn program and will be dealt with accordingly. 
Above all else, we feel that a program manager must have a 
talent fcr human understanding. He must have insight into 
behavioral patterns that indicate personal or professional 
trouble within the staff member. Through personal attention 
to the needs of the individual, he will generate a loyalty 
that will motivate the best actions from the indivivuai thus 
improving the parson for future achievements and thrusting 
the current proiect to a successful completion. 

Above all else, the program manager is the key to a 
project’s success. Sound estimates of cost and effort will 
be for naught if a competent program manager is not at the 
helm. 



33 



III. SOFTWARE LIFECTCLE 



phases a^ activities 



This chapter describes the major phases and activities 
of a software development project. With any type of 
project., whether it be developing a software system or 
building a little red wagon, a person needs to know exactly 
what it is he is setting out to do before he can even begin 
to estimate what he needs in terms of time, money, and 
effort to complete the project. Throughout the literature 
on software engineering economics, reference is made to the 
lifecycle phases of software development projects. 
Essentially, a project is broken down into parts sc that 
what may at first appear to be an insurmountable task may be 
viewed as a composite of less complex components. An under- 
standing of the phases and activities involved in the 
production of software is the first step toward answering 
the question "Where does the mcnsy go?". 

A. MAJOR PHASES 

"I • Sys te m Requ ir ern e nts /Fea sibil i tv 

We will devote considerable attention to this phase 
of the software lifecycle. Too often we charge off to 
battle when no war exists. The corporate manager must first 
determine that a real need exists in his company and that 
the need can best be satisfied with improved software or 
initially computerizing an area of his operations. The 
perceived problems, however, may be found to be solvable 
within his existing framework. 

During the system requirements/feasibility phase, 
software concepts must be delineated and evaluated and a 
preferred alternative chosen by management. 
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Once the need for a new infer marion sysnem is perceived, 
a feasibiliry study dera mines whstaer or not desired 
objectives of a proposed information system can be 
achieved within existing constraints. The study identi- 
fies the cost of proposed changes (monetary and 
organizational) and estimates the benefits of tne new 
system. On this information, the manager decides 
whether to implement the new system or discontinue the 
study. [Ref. 23; p. 233] 



A feasibility study is undertaken when the need for 
a new or better information system is perceived by an organ- 
ization. A feasibility study is a costly undertaking and 
before beginning the company should evaluate whether 
existing solutions to similar or identical problems exist 
and whether they can be satisfactorily adapted to their own 
com Dany . 

When a software development projec- is contemplated, 
the market’s existing software should be <=xamined to deter- 
mine whether the needed wheel has already been invented. In 
assessing the r egui re m-^n ts of a particular software develop- 
ment project, the existing hardware must be reviewed as to 
whether it can perform up to the expectations and demands of 
the contemplated system. If the hardware is nonexistent or 
outdated, the feasibility study must incorporate the areas 
of hardware and software. 

The four phases of a feasibility study are: 

1. Organizing for the feasibility study. 

2. Search for a solution. 

3. Feasibility analysis. 

4. Choice of a solution. [Ref. 23: p. 233] 

Phase one, organizing for a feasibility study, is 
undertaken when one or all of the following become apparent: 



1. Changes in organizational goals, olans and infor- 
matnon regunrement s. 



35 



r 



Phase One: Organizing for feasibility study 




To Phase T^vo 



[R€f. 23: p. 234 ] 



Figure 3-1 Phase One: Organizing for feasibility study. 



2. Chang‘=“s in organizational structure (e.g., 
appointment of new top management) . 

3. Changes in the environment (e.g., legislation 
reguiring the company zc supply new data to 
government agencies). 

4. Changes in technology than may make new systems 
feasible. [Ref. 2 3: p. 234] 
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If the need for change has been clearly identified, 
then management must undertake to clearly define the prob- 
lems and search out possible solutions, A feasibility study 
team is recommended for this task. The team usually 
consists of rwc to eight members with the following 
qua li f icat ions: 

1. Members should reflect a knowledge of the system 
techniques. The nature of nhe problem will determine 
whether rhis knowledge be in rhe area of operations 
research, saatistics, computer science, informa'^ion 
science or business funcaions. 

2. Members should have the ability to relate ao people 
since their work will lead them ac exchanges wiah 
many individuals in the company. Change and possible 
less of jobs always concern employees and these fears 
should be alleviated by the group members. 

3. Members should have a aherough understanding of ah= 
orq anizaaion . 

u. Members should be able ao digesa details and relate 
ahem to the overall picaure of the organization. 

5. Members should have a posiaion in management for 
clout. 

6. Members should have experience in the project under 
consideration- [Ref. 23: p. 235 ] 

Personnel may have to be hired *o meea some needed 
qua li fications. 

Afaer the aeam has been idenaified, management will 
saaae the objectives of ahe study and the related policies 
and constraints. The ream will need to know such things as 
permissible error rate, how many decimal points answers 
should be carried tc, response time r equiremenas, the number 
of users anticipaaed on the sysaem, Iccaaion of the users, 
etc. Goals are set by managemena and the feasibility study 
is tc determine whether the coals can be met within 
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Phase Two: Search for solutions 

From Phase One 




To Phase Three 



[Ref. 23: p. 237] 



Fiqure 3.2 Phase Two: Search for solutions, 

technological constraints and resource constraints of the 
coaipany. If goals cannox be niet as originally defined, 
eixher xhe goals are redefined or the project is scrubbed. 

Phase two, the search for solutions, niay take two 
forms. For a situation where major overhuals are to be done 
on a system, a fresh approach to the problem disregarding 
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Phase Three: Feasibility analysis 

From Phase Two 




Phase Four 



To Phase Four 



I 

I 

1 



TRef. 23: p. 239] 

I _ ■ 



J 



Figure 3.3 Phase Three; Feasibility analysis. 
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the existinq system is recommended. When changes to the 
subsystems within the existing structures are to be under- 
taken, then a thorough evaluation of all the information on 
the environment is recommended so that current performance 
of the system can be evaluated and changes recommended. 
[Ref. 23: pp. 237-2381 

The solutions uncovered in phase two are tested in 
phase three, feasibility analysis, regarding their economic, 
financial, organ ir at ion ai and technical viability consid- 
ering imposed constraints. The economic feasibility of 
implementing a new system is usually accomplished by 
performina a cost-benefit analysis of the proposed under- 
taking. The cost-benefit analysis will determine whether 
the benefits of the new system will be greater than the 
costs required to implement the new system. What must be 
taken into account are the costs encompassing the software 
and hardware as required. 

Increased attention is being given to organizational 
adjustments that must be made when a new information system 
or a revised information system is contemplated. "The major 
reason Management Information Systems (MIS) have had so many 
failures and problems is the way systems designers view 
organizations, their members, and the function of an MIS 
within them" [Sef. 24: p. 17], Although management informa- 
tion systems are cited, the authors include any computer 
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this approach. Both the technical and social aspects of a 
new system must be considered in the design of the system. 
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STS is a fairly recenr development in the quest 
organizational systems which are both mgre satisfying 
their members and more effective in meeting t 
requirements. This aoproach is used for redesign 
existina work systems as well as for new site desig 
[Ref. 24: p. 17j 



Phase Four: Choice of solution 

From Phase Three 



Phase Three 
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Phase Four 



Go to box 5(See Figure 3.1) 
[Ref. 23: p, 248 ] 




Figure 3.4 Phase Pour: Choice of solution. 
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In phase four, choice of a solution, the feasibility 
team recommends various alternatives to management with a 
ranking cf their desirability. If no desirable solutions 
exist, management may want to change their constraints in 
order to find a feasible solution. Although management will 
have been involved in the feasibility study as it 

progresses, it must now make a final review cf the alterna- 
tives and settle on a choice. 
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be specifie d. It should also be required that the va rious 
lev els of document at ion be c onsi stent (e.g., sub-programs 
spa ci ficat ions should be consistent with the associated 



program specification)." [Ref. 26: p 

documentation can be found in varying 
software development projects in the ph 
Functional Requirements Document 
Data Requirements Document: 

Sysrem and Sub-System Specs 
Program Specification 



. 11 ] The following 

degrees in compuoer 
ases indicated: 
Problem Definition 
Problem Definition 
System Design 
System Design 
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Da'ca Base Specification 
Test Plan 
User Manual 
Operations Manual 
Program Mainxe nance Manual 
Test Analysis Report 



System Design 
System Design 



Programming 

Programming 

Programming 



Test. [Ref. 27] 



During the coarse of a software development project. 



oral communication and written documentation must be 
balanced for the best results of a project. "A requirements 



d fo 



analysis can aid in undersxanding both the problem and the 
tradeoffs among conflicxing consxrain ts, thereby ccnxri- 



necessities musx be distinguished from bells and whisxies. 
Time and space limitations, facilinies plans for the future, 
and individual facilities requirements must be addressed. 
The money required for and rhe money available ro implemenn 



all these questions have been answered, specifications of a 
computer solution to the problem may begin" [Ref. 25: p. 

199]. To summarize, what is needed is "a complete, vali- 



and performance for the software producx" [Ref. 3: p, 37]. 
3. P reliminar y D esi an / Prod u c~. Desi gn 



the software, we are actually asking what do we want the 
software to do? We want to determine , for example, xhe 
format of the input and output. What information would be 
desired for the production of a check and how should this 
information appear on the check. Algorithms must be consid- 
ered for deductions from the basic check such as life 
insurance and health insurance plans. 



bating to the best solution" [Ref. 25: p. 199]. Absolute 




dated specification of the required functions, interfaces. 



When we look to determining the spec. 



cations of 
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A primary concern will be the size and content of 
the database. Beyond than, we will have to determine the 
layout of the database that will be most effective. If 
anything but a totally new system is being incorporated, 
plans must be made fcr conversion of the dana in the old 
system to the new system. Compatabili ty must be considered 

if new eguipment is to be adopted to existing equipment. 

The answers to these questions should be put fcrth 
in a document called functional specifications [Ref. 25; p, 
199% This document should be painstakingly prepared giving 
thorough definitions of the specifications required. The 
more complete this is, the fewer the errors will be in the 
final product, "Because it describes the scope of the solu- 
tion, this document can be used for initial estimates of 
time, personnel, and other resources needed for the project. 
These specifications define only what the system is to do, 
but not how to do it." [Hef. 25: p. 199] 

This theme of describing what and not how something 
is to be done is important for deriving the most from the 
programmers working on the project. If the how is to be 
defined ty the person writing the specifications, he may be 
limiting himself to an antiquated solution to the problem 
and not availing himself of the creativity of the program- 
mers. Herein we have once again an instance where a good 
manager will guide the development of the specifications and 
not unknowingly limit himself by doing the programmers job. 
With a basic knowledge of the system and programming, he 
will be able to clearly evaluate original solutions to the 
problems and employ the best technology available to the 
programmers. 
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^ • Pet aile d D esign 



Much hds been written about the design phase of a 
software development project. 



To reiterate, A complex system is one in which there are 
so many system states that it is difficult to understand 
hew to organize the program logic so that all states 
will be handled correctly. Tae obvious technique to 
apply when confronting thas type of situation is ‘aivide 
and rule. • This is an old idea in programming and is 
known as modularization. Modularization consists of 
dividing a program into subprograms (modules) which can 
be compiled separately. but which have connections with 
other modules. ' [Ref. 28: p. 66] 

What is now considered to be the most effective way of 
developing a software project was set forth in a classic 
article by Stevens, Constantine and Meyers in 1974 and 
subsequently refined and developed by Parnas [Ref. 29], 
[Ref. 30], [Ref. 31]. 

Zssentially, the concept of micdularization is used. 
A particular design* decisio n is assigned to one module. The 
job of coming up with an algorithm to implement that design 
decision is then given to one programmer or a group of 
programmers perhaps organized into programming teams as 
recommended by Brooks [Ref. 7; pp. 29-37]- When the work is 
modularized, it becomes easier for the programmers to under- 
stand. Communication lines can be established between 
programming teams so that questions can be answered. Each 
module is developed as an entity in itself and how it does 
its job becomes the secret cf the module. The module will 
require certain inputs and will deliver certain outputs. 
The internal workings of that module will not be revealed to 
designers of other modules. The module will then not be 
tampered with. 

The connections between modules are the assumptions 
which the modules make about each other [Hef. 32]. 
Modules have connections in control via their entrv and 
exit points; connections in data, explicitly via their 
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arguments and values, and implicitly rhrough data 
referenced by more than one module; and connections in 
nhe services which rhe modules provide for one another 
C Ref. 28: p. 66]. 



The beauty of this concepr is that development time 
is shorrened and modifications can be more easily made to 
one black box, the mcdule, when changes are required down 
the line. 



5 • Cede an d Debug 



During the code and debug phase, scfnware is actu- 
ally produced nhat meens rhe specif icax ions and is cerxified 
to meet the user's requirsmenxs. Code is said to be veri- 
fied when it meexs xhe specifications of the design; code is 
said tc be validated whan it proves xc do whax the user 
wanxs ix to do. 

When converxing daxa xo code, errors are oftentimes 
made that are not easily dexeexed. Wrong character usage 
can be caught without much trouble but correct characters 
used improperly will pass undexeexed. 



The credibility of data is often direexly related to the 
origin of coding. Coding ax the data source may lead to 
inadvertent errors due xo a misunderstanding of xhe 
coding structure or carelessness in apelying valid and 
relevant codes. Trained coders, selected and supervised 
with cars and motivated as tc xhe importance of their 
job, make fewer errors. [Ref. 23; p. 163]- 



6 • Debuggi ng a nd Test i n g 

Since computers are not forgiving in nature and 
react xo any errors, testing and debugging is extremely 
important. After each module has been codded, testing and 
debugging should be done; after each module has been tested 
separately, all xhe modules must be tested together as a 
system. System tests including acceptance testing are of 
course very important. 
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We can classify p rogranming errors according to 
three types: 

1. Syntax 

2. Code Logic 

3. Problem Logic 

Syntax errors include such problems as omitred 
parentheses, incorrectly spelled (and thus unrecognizable) 
variable names, wrong data codes and miscounted character 
lengths. Ccspilers are used to find these errors. 

Code logic errors are not as easy no rind and 
include operable snanemenns than produce incorrecn resulns. 

Some such bugs are obvious-a missoelled word or misa- 
ligned tinle on an ounput report, 'for example. Other 
errors are difficult to discern, such as nransferring 
connrcl incorrectly afner an I? statement ana byoassing 
some intended instructions . Still others are 

insidicus-fcr example, errantly substitutinq one vari- 
able name for another in an equation. The results mav 
seem undecipherab ly random. [Sef, 33: p. 311] 

Problem logic errors exist when the program does non 
adequately address the user's problem. For example, 
although a program may be correct for payroll, a wrong 
ur.d-sr standing of the tax laws or the payroll deductions by 
the programmer may render the output of the program useless 
to the user. 

Ki storical ly . tes t in g tooh a major sha^ of the 
e ffor t d ev o ted to a pro ie c t. often as much as 50 %, With 
increased emphasis being put on the front-end development of 
a program, this phase is c cnsuming less of the resources of 
the project and is generally consuming about 34% of the 
effort. 
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7. Op erations an d Main tena nee 

This phase concerns implementing the developed soft- 
ware in production and keeping that software functional. k 
number of areas are to be considered: 

1. Operating personnel and computing facilities must of 
course be available 

2. Errors that arise from usage must, be corrected 

3. Modifications must be made to the software as the 
user r eg uir aments change 

4. Changes must be made as efficiency requirements 
change. [Ref. 34: ?. 32] 



E. ACTIVITY DEFINITIONS 

Once the lifecycle phases have been defined one should 
estimate for each phase the fraction of the total amount of 
resources that are to be allocated to it. The activities to 
be performed in each of the phases should "her. be determined 
and resources assigned accordingly. [Hef. 35: pp. 625-631] 

A typical allocation of resources in custom software 
development and test is: 

1. Requirements Analysis: 

2. Preliminary Design: 13% 

3. Interface Definition: 4% 

4. Detailed Design: 16% 

5. Code and Debug: 20% 

6. Development Testing: 21% 

7. Validation Testing and Operational Demonstration: 
13 % 

Summing the four phases prior to code and debug shows 
that we allocate 46% of our total dollar there, 20% goes to 
coding, and the remaining 34% goes to the two major phases 
that follow coding. [Ref, 35; p. 630] 
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In order to enhance the reader’s understanding of just 
how the dollars axe being spent, a description of the acriv- 
ities involved is presented. A breakdown of the tasks 
performed within each activity during each phase is 
presented in Table I. The completion of each major phase of 
the software life cycle requires that various functions or 
activities be performed during each phase. We summarize 
these activities as follows: 

1. Requirements Analysis: DeTerrinaricn , specif ica-ion, 

review and up dare of software functional, perfor- 
mance, interface, and verification reqniremenTS, 

2. Product Design: Den erminaticn , specificarion , review 

and update of hardware/software architecture, program 
design and data base design. 

3. Froaramming: Detailed design, code, unit test, and 

integration cf individual computer program compo- 
nents; includes programming personnel planning, ~ool 
acauisition, data base development, component level 
Gccument ation, and intermediate level programming 
management. 

u. Test Plannning: Specification, review, and update cf 

product test and acceptance test plans; acquisition 
or associated test drivers, test tods and test data. 

5. Verification and Validation; Performance of indepen- 
dent requirements validation, design verification and 
validation, product test, and acceptance test; acqui- 
sition of requirements and design verification and 
validation tools. 

6. Project Office Functions: Project level management 

functions; includes project level planning and 
control, contract and subcontract management , and 
customer interface. 

7. Configuration Management and Quality Assurance: 

Configuration management includes product 
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TABLE I 

Project Tasks by Activity and Phase 

and Product nlegrauon 

Activity Nfquir«-ments Design Programrniftg and Test 



Requirements 


Analyze existing 


Update require- 


Update require- 


Update require- 


analysis 


system, de- 
lermine user 
needs, inte- 
grate. docu- 
ment, and 
Iterate re- 
quirements 


ments 


ments 


ments 


Product design 


Develop basic 
architecture, 
models, pro- 
totypes, risk 
analysis 


Develop prod- 
uct design: 
models, pro- 
totypes, risk 
analysis 


Update design 


Update design 


Programming 


Top-level per- 
sonnel and 
tools plan- 
ning 


Personnel plan- 
ning, acquire 
tools, utilities 


Detailed design, 
code and unit 
test, compo- 
nent docu- 
mentation, 
integration 
planning 


Integrate soft- 
ware, update 
components 


Test planning 


Acceptance 
test require- 
ments. top- 
level test 
plans 


Draft test plans, 
acquire test 
tools 


Detailed test 
plans, acquire 
test tools 


Detailed test 
plans, install 
test tools 


Verification and 


Validate re- 


V 4 V product 


V & V top por- 


Perform product 


vaiidation 


quirements, 
acquire re- 
quirements, 
design V & V 
tools 


design, ac^ 
quire design 
V & V tools 


tions of code, 
V 4 V design 
changes 


test, accep- 
tance test, 

V Sl V design 
changes 


Proiect office 


Proiect level 


Proiect level 


Project level 


Project level 


functions 


management, 
proiect MIS 
planning, 
contracts, li- 
aison. etc. 


management, 
status moni- 
toring, con- 
tracts, liaison, 
etc. 


management, 
status moni- 
tonng. con- 
tracts, liaison, 
etc. 


management, 
status moni- 
tonng, con- 
tracts, liaison, 
etc. 


CM/QA 


CM/QA plans, 
procedures, 
acceptance 
plan. Identify 
CM/QA tools 


CM/QA of re- 
quirements, 
design; proj- 
ect standards, 
acquire 
CM/QA tools 


CM/QA of re- 
quirements, 
design; code, 
operate li- 
brary 


CM/QA of re- 
quirements, 
design; code, 
operate li- 
brary; monitor 
acceptance 
plan 


Manuals 

3: p. 


Outline portions 
of users’ 
manual 

50 j 


Draft users’, op- 
erators’ man- 
uals, outline 
maintenance 
manual 


Full draft users' 
and opera- 
tors’ manuals 


Final users’, op- 
erators’, and 
maintenance 
manuals 
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identifica-cion , change control, status accounting, 
operation of program suppor* library, development and 
monitoring of end irsm acceptance plan; qualiry 
assurance includes dsvelopmenr and moniroring of 
proiect standards, and technical audits of software 
products and processes. 

8. Manuals: Development and update of users’ manuals, 

operators' manuals, and maintenance manuals, 
f Ref . 3: pp. 4 6-5 0 ] 



C. SUMMARY 

A SC few are develcpmenn project’s major ohases and the 
acrivi-ies of each phase have been presented. We feel nhat 
a manager needs a sound understanding of nhis aspect oi 
software engineering economics if he is no net only under- 
stand but also contribute to his organi ration ' s development 
effort. The foundation of knowledge that is laid here 

ccncsrr.rnq the software lifecycle (and as is true for all 
the ideas set forth in this research) will be built upon and 
refined as the organization interacts wrth prciassionals in 
the computer industry. With a sound, working knowledge of 
software engineering economics, managers will increasingly 
find that they are assisting in the development of an infor- 
mation system that fulfills their needs in an efficient and 
effective manner. 
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IV. EFFORT, TIME COST E STIMAT ION 

Herein we look specifically at the factors affecting 
effort, time and cost estimations. We feel that focusing 
cur attention on this particular area of software engi- 
neering economics is essential for it is here that the 
organization’s life-line is tapped. Effort, time ani cost 
estimates will directly affect the stability and solvency of 
a company. Inaccurate estimates according to Murphy's Law 
will prove to be underestimates and accordingly drain the 
company of added resources that may or may not be conven- 
iently available. A project may be scuttled due to the 
inability to provide additional support. 

A. TIME AND EFFORT ESTIMATING 

^ • Ex perience an d Judg emen t 

Every estimate is influenced to seme extent by the 
experience and judgement of its author. Some items influ- 
encing the estimate are so well understood that judgement 
seems to be replaced by the mere mechanical application of a 
rule, while others depend heavily upon the experience of the 
estimator. [Ref. 36: p. 48] The person responsible for 

ensuring the validity of an estimate should remain well 
aware of the skills and qualifications of the individual who 
prepared the estimate to give him/her a basis for deter- 
mining its accuracy. 

2 • Froar amme r Pr odu ct i vitv 

Programmer productivity plays a major in part in 
estimations of the amount of time and effort that will be 
expended on a software development project. The paragraphs 
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that follow focus on some of rhe more important aspects of 
productivity. As producriviry increases, software develop- 
ment costs decrease. In addition to worker quality and 
motivation, productivity depends on the use of advanced 
technology and the proper use and training of workers to 
effectively interface with the new technology. Shorr-term 
investment in training and jcb modification should lead zo 
savings in the long-run due to increased productivity. 
[Hef. 37] 

There are certain ncn-human elemenrs nhat can have a 
great effect on producrivii: y. The developmenr environment 
is a key facror in this regard. One musi: ensure that 

adequate hardware and software support is available to rhe 
programmers. It is not uncommon for projecrs to become 
bcttlenecked because throughput capacity, disk space, CPU 
capacity, or the like have been exceeded. The demand for 
these computing resources during design, development, inte- 
gration and t-^st is generally greater than curing 

operations. The delays caused by such bottlenecks resul- in 
high levels of frustration and lower productivity among the 
programmers. [Hef. 38] 

It should also be noted that poor programmer produc- 
tivity is as much the result of bad management decisions and 
planning as it is the result of inadequate tools, or lack of 
talent. Productivity is affected by an organization's 
structure, goals, product type and experience in developing 
software. Care should be taken to ensure that an organiza- 
tion's software development process does not become a 
hindrance to productivity through imposed inflexible manage- 
ment procedures. [Ref. 39] 

According to Jack Stone there are certain changes 
that could be made to the programmer's physical environment 
to increase his/her productivity. One of his suggestions is 
to give each programmer a private office to ensure quiet 
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s ur EO un din qs rather than groupinq the programmers together 
'•like cattle in a box car". Another of his suggestions is 
to ensure that the programmer has available to him/her state 
of the art computer services (a CRT terminal with on-line 
interactive operating system controls, editors, compilers, 
and debug facilities). [Ref- 40] As previously discussed, 
improved programmer productivity is among the potential 
benefits that may be derived from the use of SDE. 

3 • Code Produc ti on Rat es 



A working standard of the typical code production 
rate per programmer man-month is 1 object instruction/ man- 
hour, which is equivalent to 156 instructions/man-month, or 
1870 ir.structions/ma n-year for non time-critical software. 
Wide variations in programmer productivity do exist however. 
[Ref. 35; p. 631] 

4* 23. s Lc w?. nlc^diT^ Pdt'tsrr. 0v3r 

Research on the man-effort loadings of mecrum to 
large scale software development projects has revealed a 
basic manloading pattern over time. Initially, there is a 
rise in man-effort followed by a peaking and then an expo- 
nential tailing off. The time varying nature of a project's 
work profile is to be expected since software development 
itself is a time dependent process. [Ref. 41: p.128] 



Consider the following rationale. A software project 
can be thought of as entailing' the soluricn of a frxed 
number of problems. At each point in time, t, bgth the 
number of unsolved problems available for solution and 
the level of skill available for solvina problems will 
vary. since the rate of problem resolution is influ- 
enced by both factors, it too will be a time dependent 
process. Presumably, consumption of project resources 
reflects the rate of problem resolution, hence, the time 
varying nature of the manloading curve. [Ref. 41: p, 

128] y L y 
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B. COST ESTIHATING 



1 • Cost Consider at ion s 

A detailed understanding of the factors that impact 
on rhe cost of a software development project is required in 
esrimatinq its cost. Two major problems are involved in the 
estimation of software development costs. One of these is 
the level of uncertainty and risk. The other problem is the 
lack cf a quantitative historical cost data base. [Sef. 42: 
pp. 16-171 

Three factors contribute to the amount of risk and 
uncertainty involved. These are that the requirements are 
subject to change, something new may be required during the 
development process, and risks ere inherent in the software 
development process itself. [Ref. 42: p. 17] 

For a good software cost estimate one should work 
from firm requirements, understand the required product 
well, and carefully manage the development cycle to ensure 
that coding does net begin before the design has been 
thorcughlv worked out, verified, and validated [Ref. 42: p. 

17]. 

Without accurate measures of prior costs it is 
extremely difficult tc estimate the cost of a new project. 
To solve this problem cost summaries should be archived and 
distributed by the project manager of the development effort 
to the appropriate personnel for estimation purposes. 
[Ref, 42: p. 17] 

2 • Factors I nfluen cinq Software Develo pmen t Cost s 

The key factors influencing the cost of a software 
development project may be divided into the following four 
categories : 

1. Requirement Factors 

2. Product Factors 
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3. Process Factors 
U. Resource Factors 



a. Requirement Factors 



(1) . Qua lit V of S peci f ica ticns . Incomplete 
requirements definition is a major cause of cost overruns. 
The developer interprets the vaque, poorly written require- 
menrs, prices the scfrware package on the basis of that 
interpretation, and proceeds to design the software on that 
same basis. [Ref. 42: p. 17] 



One of rhe keys to accurately costing 
software is to devote extra effort in solidifying the 
requirements before entering the detailed design phase of a 
project. Understanding the requirements is the basis for 
analysis of many of the other costing factors, includinq 
difficulty, interfaces, size, tools, use of existing soft- 
ware, and data base complexity. Poor estimates of software 
size or data base complexity are often blamed for cost over- 
runs, when the actual reason for errors in these estimates 
is incomplete or inadequate specification of requirements at 
the outset of the initial software costing. [Ref. 42: p. 

17 ] 

(2) . S ta bi lity of Requ ire ments . There are many 
projects for which the well specified requirements against 
which the detailed design is prepared change during the 
project. It is the responsibility of the project manager to 
fully understand the software requirements and to ensure 
that it is understood that changes in the requirements base- 
line are just that, changes! The project manager should 
then define the cost and/or schedule impact so that the 
change may be fairly evaluated. If the change justifies the 
estimated impact on the pro ject, a decision to incorporate 
it may then be made. The change should then be reflected in 
the requirements specification and incorporated into the 
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design; its impact on the project budget and schedule 
should also be stated. Once -he impact of changes on the 
project is known, many changes that at first appeared 
attractive lose their appeal. [Ref. 42: p. 17] 

b. Product Factors 

Product factors are those factors derived from 
the character istics of the software product to be develooed 
and delivered, including both code and documenta-^ion. 
Following is a discussion of the six product factors. 

(1) . Softw are Size . A very common method of 
costing software is to estimate the number of instructions 
to be developed and multiply by a "magic number" (dollars 
per instruction) to get the estimated development cost. 
Although this estimating technigue is net very precise when 
used alone, it can be very useful when used in conjunction 
with the other factors. 

Significant sizing considerations include 

the icllovfinc: 

1. Care must be taken to isolate the deliverable soft- 
ware from the nend eli verable test software, 

simulations, and support software, which should be 
less costly to produce. 

2. As the size of the software increases, other factors 
such as complexity, interfaces, and the number of 
people involved, begin to have a greater influence on 
t he CO st . 

3. When trying to use size as a costing parameter, care 
must be taken that the cost base being used is 
derived from the same sizing parameter. Projects or 
companies may track costs by lines of code, number of 
object instructions, number of executable source 
statements, total instructions or lines of code 
developed, or delivered instructions or lines of 
code . 
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4. When using size/cost factors, consideration should 
also be given to productivity differences between 
languages, 

5. When object code sizing estimates are based on 
similar existing software, consideration should be 
given to differences in the expansion ratio from 
source to object instructions between different 
HCL's, compilers for the same HOL, or different 
operating systems. 

6. As size increases, rhe number of individuals involved 
in the development effort increases and the amount of 
time spent in intercommunication and coordination 
becomes significant, driving the cost versus size 
from linear toward some -higher multiple. [Ref, 42: 

pp. 20-21] 

(2) . D if fi cult V. One of the more important 
factors affecting software development costs is the relative 
difficulty of the software application. Software personnel 
productivity (and therefore cost) will vary with the type of 
system being developed. Real-time applications are gener- 
ally considered to cost u p to five times as much as HOL 
non real-time applications. [Ref. 42: p. 21] 

(3) . R el ia bili tv Reguir ements. According to 
Bruce and Pederson the reliability of a software program may 
be determined by four major criteria. These are: 

1. the program must provide for continuity of operation 
under nonnominal circumstances; 

2. the design, implementation techniques, and notation 
utilized must be uniform; 

3. it must yield the required precision in calculations 
and outputs; and 

4. the program must be implemented in a manner that is 
understandab le . 
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As the level of requirements for handling 
nonncminal conditions increases so does the amount of veri- 
fication effort required and, along with it, rh<= ccsz. 
[Ref. 42: p. 21] 

(U) . E xter n a l Interf aces . Cosz increases as 
the complexity of external interfaces increases due no the 
additional effort required for design, implemennation, and 
innegranion [Ref. 42: p. 21]. 

(5) . L an aua ae Experience has 

shown than in takes an average programmer aboun the same 
amount of effort to write a line cf code in high order 
language as in an assembly language. Apparennly the thought 
process required to write a single snatemenn is almost inde- 
pendent cf the language in which the statement is writnen. 
It will take a programmer significantly longer to write a 
program in assembl'V language than it would to write the same 
procram in HOL, since a typical HOL statement expands tc 
5-10 assembly language snanemenns. Early in a projecr a 
programmer’s familiarity w ich a language will affecr the 
cost per srateraent more than the language being used. 
[Rsf. 42: p. 21 1 

(6) . D oc um enna ticn Requir ements . The cost, 

factors associated with the preparation and acceptance of 
required documentation must be evaluated along with all 
other cost factors [Ref. 42: p. 21]. 

c. Process Factors 



Management structure, management 
tools, use of available software, and data base 
all software costing factors associated with the 
process. A discussion of these factors follows. 



contrcls, 
methods are 
development 
[Ref. 42: 



p. 21] 
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(1) . tlanaqe msn t Structure. Management struc- 
ture effects the organization’s policies regarding the 
allocation of resources f o r a software development project 
[Ref. 42: p. 22], If the structure is such that upper level 
management arbitrarily imposes standards without under- 
standing their purpose, use, or implications on the software 
development process, the standards may prove to be counner- 
producrive. Management should tie software development to 
organizational and product goals and ensure that the process 
is usable at the working level. [Ref. 39] The structure 
should be such that the programmers and engineers are able 
to get what they need when they need it without the hassle 
of having to get requests through an inflexible approval 
chain. 

(2) . M anage men t Con trols. This factor covers 

the cost of project support in such areas as management 
information processing, scheduling support, and clerical 
suDDort. The cost estimator must realize the need for "his 
type of suoport and have some understanding of the relative 
magnitude of this type of project cost. [Ref. 42: p. 22] 

(3) . D evelo pme nt Methods. This factor attempts 
to quantify the impact of various development methods. The 
development methods of interest include such approaches as 
top-down design and testing, structured programming, use of 
chief programmer teams, and use of structured walk-throughs . 
[Ref. 42: p. 22] 

(4) . Too Is . The cost estimator must consider 
how the software will be developed, tested, and maintained 
and what tools will be needed to accomplish these tasks. 
For some projects the development of software and hardware 
tools is a major cost item. The cost estimator must deter- 
mine whether compilers and other tools are required, 
available, need to be converted, or need to be developed. 
The costs associated with the tools are a function of the 
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tool complexity, use, features, and maturity. Experience 
provides the best basis for analyzing the cosr impact of 
support software and tods on overall project cost. 
[Bef. 42: p. 22] 

(5) . Availa ble Sof- ware. Significant reduc- 
tions in the cost of projects may be achieved through the 
use of exisxing software. Adapting the existing software as 
part of a system requires analysis of the software aoar-: 
from the new development. The cosrs for modifying the 
existing software can in this way be dererninec subjec- 
•cively. Care musr be taken to include the cosn of 
interfacing the modified sofzware no the new software and 
revalidatina the requirements. [Ref, 42: pp. 22-23] 

(6) . Data Base. The size, complexity, and 
special file access requirements for the data base are very 
important parameners in deriving an accurate software devel- 
opment estimate. The cost estimator must review 'he data 
base reauirements and subjectively analyze their impact on 
cost. [Bef. 42: p. 23] 

Q. Resource Factors 



Software development costs for a given project 
may vary substantially, depending on such factors as the 
experience of the available personnel, the quality of the 
project staff, and availability of development computer 
resources [Bef. 42: p. 22]. 

(1) . Number of P eo ple. With pro jects that 
require large staffs the major contributor to the reduction 
in productivity (increased cost) is the increase in the time 
needed for communication between the people [Bef. 42: p. 
23]. 

(2) . Experien ce of P eo ple. Existing data indi- 
cates that there is no direct correlation between the number 
of years of experience that a person has and his/her 
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productivity. However, experience with a specific type cf 
application does have an effect on the development effort 
required. Generally speaking, a programming group will 
require from 50-100'^ more effort to develop a variant of a 
previously developed, familiar program. [Ref- 42: p, 23] 

(3) . Personi^l P erformance . Individual produc- 
tivity variations are to be expected in the development of 
software due to the fact that it is an analytical, and seme- 
rimes creative activity that requires abstracr reasoning. 
Nonerheless, experienced estimators have found variations in 
productivity to be as high as 10:1. The assessment of 
productivity is extremely important because cost estimation 
is generally reduced to deriving a productivity figure per 
unit cf effort per person within a given skill category. 
The use of such average productivity figures for estimating 
cost tends to even out for large projects, but may prove to 
b® disastrous for small projects. [Ref- 42: p. 23] 

(^) • Availabil itv of Com pu t ^ng Resources. ks 
the requirement for computer time increas=>s during the 
development cycle, the impact of insufficient computing 
resources on schedule and cost increases. The amount of 
computer time required for a given development effort is 
easily underestimated. [Ref. 42: p. 23] 

(5) . S uitabil i ty of Co mputing Re so urc es. 
During the software maintenance phase, when there may be 
little capacity available for corrections, modifications, or 
required test drivers to verify changes, there is an asymp- 
totic effect on development costs as the hardware speed and 
memory size constraints are approached which could prove to 
be crippling [Ref. 42: pp. 23-24]. A normal person would 

not ordinarily jump into a sports car and speed off down 
some winding mountain road he had never driven on before in 
the black of night. If he did, without warning, he could 
find himself at the bettom cf a canyon, surrounded by steep 
cliffs. 
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3 . C ost Ss tima t ir.q Pro cedures 

Traditional cost estimating procedures begin by 
fixing the size of each activity and dexermining its starx 
date and duration. When and if it becomes necessary to do 

so, adjustments are made to account for the skill levels of 
the assigned personnel, the complexity of the project, and 
the degree of uncertainty in the requirements. The amount 
and type of manpower and resources are then converred to 
dollar costs. Cxher dir acx costs, such as documentaticr. and 
xravel, are also added in. 

Traditional cost estimaxina methods include; 

1. Top-Down Esximaxing; The estimate obtained using 
•^his method is based on the total cost or the cost of 
large portions of completed projects. A problem with 
this method is that it carries with it the risk of 
overlooking important rechnical problems that may not 
be readily apparent. [Hef. 35: p. 618] 

2. Similarities and Differences Estimaxing: In tnis 

method jobs are broken down xo a level of derail 
where the similarities to and differences from 
previous projects are most easily recognizable. 
Those units that cannot be compared xo previous 
projecxs must be esximaxed by some other means. 
[Ref. 35; p. 618] 

3. Ratio Estimating: 

The estimator relies on sensitivity coefficients 
or .exchange ratios that are invariant (within 
limixs) to the details of design. The software 
analyst estimaxes the size of a module by its 
cumber of objecx instructions, classifies it by 
type, and evaluates its relative complexity. An 
appropriate cost matrix is constructed trom a 
cost aata base in terms of cost per instruction, 
for that tvpe of software, ah that relative 
complexity level. [Ref. 35; pp. 618-619] 
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The appeal of using this method is in its 
simplicity, speed, convenience, and usefulness in a 
variety of environments. A major shortcoming is in 
the lack of a valid cost data base that covers a 
number of estimating situations. [Sef. 35: p, 619] 

4. Standards Tstimaring: In standards estimating, 

s ysremat ical ly developed standards of performance are 
depended upon. New tasks are calibrated from these 
standards. This nethcd is reliable only for repeat- 
edly performed operations that have been well 
documented. The rub is that the same software devel- 
opment projects are not performed over and over 
again. [Ref. 35; p. 619] 

5. 3cttom-Up Estimating: Government research and devel- 

opment contracts are most generally estimated using 
the bottora-up approach. A work break down is done on 
the project until it is reasonably obvious what steps 
and resources are required for each task. The costs 
are then estimated for each task and a pyramid is 
developed to estimate the total cost for the project. 
Using this technique, the estimating assignment can 
he given to the people actually doing the work. One 
problem with this technique is the inavailabili-f-y of 
the total cost structure at the inception of the cost 
estimating job. [Ref. 35: p. 619] 

^ t Sst imatina R elationshi ps and Phase 

Interrelation sh i os 

Software cost estimations should include the effects 
cf resources consumed in one lifecycle phase on subsequent 
phases. A large contribution to the resource requirements 
for any one phase derives from the ways in which the ether 
phases are completed. An important factor affecting the 
utilization of resources is the need to conform to a 
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dev -aiopmenx plan. The plan is an essential aianagement tool 
for ensuring that -he needed resources are available for rhe 
pro jeer at the right rime and in the correct ameunt. 
Changes in the plan, whether caused by changes in require-^ 
tnents or by failure to meet commitments, may affecn 
cost-driving parameters. [ Hef. 43; p. 70] 
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V. THE ART AND SCIENCE OF SOFT WARE COST ESTIMAT ION 



Until absolutely reliable, comprehensive methods of 
estimatinq cost and effort in software development projects 
are developed, the techniques will be referred to both as an 
art and a science. We appropriately use the term science as 
estimatinq techniques are becoming more and more accurate 
and comprehensive. .Mathematical and scientific principles 
are increasingly being applied to all areas of cost and 
effort estimation. Researchers are now developing aicdels 
that can be used in numerous environments. 



CURRENTLY AVAILABLE METHODS FOR SOFTWARE COSTING 



Many models estimating cost and effort exist on the 
marke*. today and generally cover the time from the design 
and specifications phase thru the test and debug phase and 
the beginning of operations. They can ordinarily be classi- 
fied as theoretical cr empirical. Theoretical models are 
those based on global assumptions such as the rate at which 
people sclve problems. Empirical models use information 
from former projects to evaluate current projects and derive 
basic formulas from the available information in the data 
base. [Ref. 3: p. 511] We will present a number of avail- 
able cost and effort estimating models according to their 
classification as static, dynamic or dynamic transportable 
models. We will examine some models in more detail than 
ethers to give the reader added insight into the complexity 
of estimating cost and effort. Some of the more significant 
features of the models will be pointed out. We will then 
enumerate criteria which may be used to judge a model for 
estimating cost and effort in software development projects. 
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1 • c Mo de Is 

Models that do not trear time explicitly and do not 
have the capability to adapt to the actual behavior of the 
system at any instant of time during the lifecycle are 
termed static models. 

a. Doty 

The Doty model estimates the manpower, cos~ and 
develcpmenr time for sof-ware development projects. System 
size is estimated by comparisons of the system under consid- 
eration to comparable known systems. The model is therefore 
empirical. Doty found that the writing of high order 
languages (HOL) and assembly language instructions takes the 
same amount of time. Since HOL programs are smaller than 
assembly language programs, productivity is increased with 
HOL programs. Clarity and maintainability are higher with 
HOL. [Ref. 2: p. 108] 

b. "SOFCOST" 

In recognition of the need to establish good 
oost estimations before proceeding on a software development 
project, Grumman Aerospace Corporation has developed an 
empirical model to provide viable, credible cost estimates. 
Before completing its own model, Grumman used the Price-S 
model to estimate costs. Presently, both the "SOFCOST” 
model and the Price-S model are used in parallel as indepen- 
dent cost estimates to act as checks and balances for 
estimates of the project system analyst. "SOFCOST” allows 
the analyst to estimate the effort and elapsed time to 
complete a software development project. It is a parametric 
model developed from statistical software history. This 
empirical model uses for its primary parameter functional 
size. The basic estimating relationship is influenced by: 
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1. Experiencs 

2. Complexity 

3. Enviroament 

4. Technology 

5. Hardware 

6. Reliability 

7. Language 

8. Requirement Definiticn. 

The model operates interactively wirh the user 
to dev-elcp a software work breakdown structure (5W5S) , a 
funcricnal size marrix for the SW’BS and ohe time and effort 
computed for each item in the SWBS. 



There are five levels to the SW3S, the computer program 
configuration item, the category of software, the func- 
tions per category and two outout levels - task and 
phase. The two output levels provide the manoower tasks 
of technical, support, management, configuration control 
and documentation' per development phase of definition, 
design, code, test, inter oration and acceptance for each 
function in the SwBS. The number of system computer 
resource hours is also comouted and orovided as output. 

* "SOECOST" also derives an elapsed time schedule for 
each of the functions in the S>JBS oroviding durations 
for each of the phases included in 'Level Five of the 
5WBS. A cumulative schedule is comouted oroviding for 
overlap in each phase. [Ref. 44: p- 674] 



Grumman 's research included 30 different medals 
and a review of research conducted by industry and govern- 
ment. The work resulted in a requirements and design 
document for an in-house model. The model not only included 
prior software/cost relationships but also charcter istics 
unique to the Grumman environment. 

Research concluded that the primary cost driver 
is executable lines of source code. "SOFCOST'* was therefore 
designed to aid the user in estimating the number of lines 
of code. The estimator can make comparisons between his 
function and comparable functions found in the data base 
including function and size as its key parameters. The 
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determination of size of a project is thus a critical factor 
and one that is addressed using the judgement of the 
analyst. 

"SOFCOST" has three objectives; 



1. to construct an SSES, 

2. to determine a credible size for the functions 
being estimated, 

3. to estimate software cost and schedule for each 
functicnal task. [Ref. 44; p. 674] 



As is becoming increasingly common in linerature 
on the topic, Grumman feels that the interactive user devel- 
oping an estimate for cost and effort for a project should 
be knowledgeable in computer software design and the partic- 
ular system's reguire ments. The SW3S will be established in 
an interactive session. After the five levels are 
ccmoletec, the user interacts with the program to answer 
questions that affect the basic cost computation. Costs are 
given in manhours or manmonths ana elapsed time schedules 
are displayed. 

Translator 1 establishes the SWBS. Translator 2 
establishes a size estimate for all functions in the Sw3S 
using functions of a comparable nature from the database. 
Translator 3 of the program takes the output from translator 
2 and computes manpower effort and schedules elapsed time. 
It is here that the estimator begins to interact to deter- 
mine the adjustments to the basic estimates. Language is 
first considered. Prior studies showed little difference 
between productivity of HOL. Differences occurred in the 
productivities of HOL 's' compared to assembly language in the 
order of 2 or 3 to 1 improvement in productivity (this is in 
keeping with Doty's findings). 
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After the language type is established in Translator 3 
and an adjustment made in the size of the source code 
for language the basic manpower versus line of code for 
relationship in the model is exercised. ’*SO?COST" 
computes the effort for the phases of design, cods and 
test with a parametric equation for each phase. The 
effort computed during the design phase includes those 
steps in the software development cycle of requirement 
definition, preliminary design and astail desian. The 
code phase equation output includes coding, debugging 
and module test. The test phase effort includes 
subsystem, system, integration, and acceptance testing. 
The equations for the design, code and test efforts were 
regressed from historical data published from studies 
conducted by SDC, GBC, IBM and ISW and from actual data 
produced at Grumman. These regressions when taken with 
various combinations of the ' published source data 
produced correlation ccef ficients^ in excess of 851 when 
ocnverted to the log-linear form. The F value measure 
of statistical acceptabi lity based on the number of 
observations in the regression were on the average 
greater than 200 and indicative of repression sianifi- 
cance. [Ref. 44: p. 6 77 ] 



Interactions are then performed to adjust th 
basic computation effort. Thirty questions are asked th 
user and he evaluates each on a scale of 0 to 10. Th 
inputs are used to derive a productivity index factor 
Adjustment factors are computed for each question 

Individual adjustments are weighted. Table II lists th 
adjustment factors in weighted order. 

An adjusted manpower effort is computed afte 
all of the individual adjustment questions have bee 

ans we red . 



This adqusted effort is then distributed among the 
phases or definition, design, development, test, inte- 
gration and acceptance in accord with the results of 
published history. This is a variation of the standard 
40-20-40 allocation. This adjusted computed effort 
represents the technical effort expended upon the 
embedded program (application, tactical) by the 
personnel assigned as programmers, analysts, systems 
engineers, etc. Translator 3 then takes this computed 
eftcrt and determines the support, management, and 

con riqur ation/quality control efforts as some function 
of the technical effort. Both the documentation and 

computer resource efforts are computed separately using 
a parametric eauation relationship' formulated for these 
tasks. [Ref. 44; p. 678] 
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TABLE II 

Adjustaent Variables by Decreasing Weight 



Percent 
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Number o 
Percent 
Percent. 
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tate of the art 
splays 

uip excluding displays 
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rdwar e/so ftw are develop men- 
on technique employed 
rated for the program 
gn employed 
utilized as a design 
esign 
ogra mming emplovod 
control programming design 
experience o f Personnel 
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m<=r team technique employed 
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cazioRS 

onr.el experience 
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reauiremenzs alone 
— ^ 



goal 



r 1 nszr uczi on wort 



Fercenz of user/cbnzract or inzerface coraplexitv 

t Ref . 4U: p. 677 ] 



For scheduling, elapsed zime is compuzed bozh as 
a function of the compuzed manpower effort and also as a 
function of the adjusted lines of code. Start and end dates 
are compuzed for each phase. An optimized schedule is 
ouzput and differences bezween planned schedules and opzi- 
mized schedules are highlighzed. Reguiremenzs documenzs 
usually dictate planned schedules and recognition of accel- 
erations and/or stretchouts that might happen if zhe 
planned/ contract schedule were followed. 
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Thus, '•SOFCOST” uses historical dara and empir- 
ical data from the environment to develop estimates of cos- 
in manhours or manmonths and scheduling for various phases 
of a project. The interactive sessions with the user allow 
a more clearly defined SWBS. The primary cost driver was 
found to be executable lines of code. The basic computa- 
tions are adjusted by an interactive session with the user 
in which specific en vir onm ental factors are evaluated and 
accounted for. 



The key factors in this model that are critical 
to the estimation effort are the initial sizing of the 
project and the determination of unique environmental 
factors that affect costing and scheduling. In both of 
these activities, the judgement of the estimator as he 
interacts with the computer is critical to the success of 
the project. 



c. Lifecycle Cost Estimating 

The bottom-up decomposition m=-hocoiogy and a 
top-down regression analysis is used at the conceptual 
requirements level to provide fast and accurate estimates of 
software lifecycle costing (LCC) employing unique software 
structures. The software structural model is further 
analyzed and manipulated to give useful design alternatives 
in the form of such criteria as program control, logic 
paths, and data transfer that improve the operational quali- 
ties of the software and provide minimum LCC designs. This 
technique seeks to obtain a uniquely realizable decomposi- 
tion strategy and finally give a machine designed 
cost-effective software structure. Silver feels that the 
current method of using an empirical top-down approach and 
multiple regression analysis employing extensive data bases 
to estimate software sizing and costing is unsatisfactory. 
The uniqueness of each software package precludes this 
approach . 
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The overall problems of proaram management and cost 
ccnrrol, as well as the selection of cost-effective 
design alternatives are addressed by using a combined 
Graph Theory "bent oms-up " decomposition methodology to 
provide accurate and rapid assessments of both rechnolo- 
gical feasibililty and' economic risks in conjunction 
with a "tops-down” regression analysis employing cost 
estimating relationships (CERs) . At tne sortware 

reguirements and conceptual level, structural decomposi- 
tion identifies critical milestones and exposes 
subsequent cost drivers through the specification of 
connectivities and paths which yield minimum Life Cycle 
Costs (LCC) . This is accomplished bv utilizing the 
properties of agglomera tive polythetic' clustering to 
define a topology for determining objective decomposi- 
tion strategies related to computer sortware structures. 
The mathematical basis for mapping the software struc- 
ture onto a particular graph merric space is discussed 
in nerms of formulating a duality index for operational 
srructural partirioning. The use of oonential mul'i- 
arrribure ss mi-men rics is illustrared' wirh a view 
rewards obtaining an opriaial, decomposition 3rrat<=av and 
ultimately proviae machine designed' cost-effective ' soft- 
ware structures, f Ref , 45: p. o65] 



Silver found that the traditional methods fail 
to provide a comprehensive and useful software management 
equation that has terms that are functionally separable and 
independently linearly related to system qualities such as 
file structure, memory requirements, and number or applica- 
tion programs. The equations are ail too often complex. 
The subjective role cf the estimator is not accounted for. 
Silver feels that the top-down approach does not give the 
necessary accuracy and certainty of estimations to be 
exhaustively useful in estimating cost and effort in soft- 
ware development projects. A methodology should give 

accuracy and certainty early in the development process of 
the cost and effort involved. 

"The assumption is inherently made that attri- 
butes of design quality at the requirements level are 
sufficiently manifest in the structural charact eristics of 
the design process itself, so that they can be costed in 
detail. Furthermore, the analysis of a. given software 
structure is an appropriate vehicle for comparing different 
strategies on a cost-eff ect ive basis." [Ref. 45: p. 667] 
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for 



Atremprs have been made to explain a methodology 
the characterization of rhe software design process in 
terms of a software structural framework. 

The essential conclusion reached is that software struc- 
tural decompositions may indeed serve as rhe basic 
underpinning for the design activity and associated 
cost/performance s pecifi camions at the requiremenms 
level. C Rsf. 45: p. 667] 

Our lock at this method is concluded with the author’s 
rem ar ks: 

The ccn elusions emanamina from this study will be 
deferred to a more comprehensive oaoer dealing with the 
details of the methodology. The ihment of this investi- 
gation is to lay the foundation for decomoositicn and 
recombination without resorting to excessive riacr, 
while at the same time reoort some interestina results. 
[Ref. 45: p. 671] 

d. GRC 

Cost is figured as the non-linear function of 
the number of delivered instructions. This model ha^3 
numerous different estimating relationships which are diffi- 
cult to summarize. It has a number of good features, 
inclufing a thorough definition of the quantities being 
estimated and a set of relationships for estimating such 
quantities as training and installation costs and labor- 
grade distributions. Some drawbacks, however, include the 
use of ’number of outputs formats’ as the basic size param- 
eter and seme evident typos or mistakes in the 0.0 values 
given in the effort multiplier tables. [ Hef . 3: p. 519] 

System development cost is generally reduced if excess 
processor capacity is available, especially for virtual 
memory systems. The model considers the maximum processor 
capacity utilized in estimating the constrained software 
cost. [Ref. 2: p. 105] 
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e. TRW 

The empirical TRW-Wolverton Model assumes that 
the total effort exerted in completing a program is linearly 
proportional to the number of instructions to be produced. 
The following is used in this model: cost-per-instruct ion 

matrix, organized by software category (control, I/O, pre- 
processor/posx-processor , algorithm, data management, and 
rime- critical) and degree of difficulty (old program- easy, 
medium, hard; new pr oar am- easy , medium, hard). An histor- 
ical computer usage marrix is kept by category of sofrware 
to estimars rhe cost of computer rime needed for a project. 
The nex cosr becomes a product of cost per insxrucrion and 
the pro jeered number of instructions to be produced. 
Wolverxon has nored in his analysis that pasr experience 
does nor impacx on programmer productivity signif icanxly . 
[Ref. 2: p. 104] The heart of rhe esrimate is a number of 

curves shewing sofrware cost per object instruction as a 
funcricn of rhe relative degree of difficulty (0-100), 
novelty of application, and type of project [Ref. 3: ?. 

512]. Software is broken into parts and costs estimated 
individually in the best use of rhe model. "This model is 
well-calibrated to a class of nea r- real-time government 
command and control projects, but is less accurate for some 
other classes of projects. In addition, the model provides 
a good breakdown of project effort by phase and activity." 
[Ref. 3; p. 513] 

2 . D ynamic Model s 

These models use real time input and indicate where 
we are now and where we are going at a particular instant in 
time. 
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a. TRW (SCEP) 



The new TRW Software Cost Sstitnating Program 
(SCEP) was developed by Boehm and Wolverton. This model was 
developed using the set of criteria presented later to eval- 
uate software cosx estimating models. Comments on this 
model's performance according to the criteria set forth will 
be given later in the overall analysis of the models. 





Walston and 










This model 


gives a me- nod 


for 


es“ ima ting 



programmer productivity. Programmer productivity is 
measured in the rate of production of lines of code (LOC) . 
Given an estimate of the lines of code to be produced, the 
model estimates the total man-months of effort re:quired. 
iMan-mcnths become a function of the LOC to be produced. 
From the data base of IB:i-?ederal Systems Division (I5ii-FSD) 
consisting of 60 proiects [Ref. 3: p. 406], a set of rela- 

tions was developed to be used for cost estimation 
processes. The relationships are: 

1. productivity vs percentage of new code 

2. productivity vs percentage of effort at primary loca- 
tion 

3. productivity vs percentage RJE use 

4. delivered source documentation vs delivered code 

5. duration vs delivered code 

6. duration vs total man-month effort 

7. staff size vs total effort 

8. computer cost vs delivered code 

9. computer cost vs total man-months of effort 

The main problem with the model is the diffi- 
culty in determining how change in the ratings of 
productivity of cost drivers is due to other correlated 
factors or by double counting using four factors to account 
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ii 




for rhe use of aiodern programming practices [Ref. 3: p- 

517 ], 



c. Aron Model 

Aron found that large system building efforts 
increase gradually, reach a peak, and rhen decline to zero. 
The peak time and system testing seem to coincide. He 
investigated the following ways of estimating software 
costs: experience, constraint, units-o f -wcrk , and quantita- 

tive. Experience depends on exposure to similar jobs in 
similar environments. Using constraints, the manager just 
aarees to do a job within given constraints. In the units- 
cf-wcrk approach, the job is broken down into smaller units, 
cost is estimated for each unit based on past experience 
with units of the same size. When quantitative estimation 
is used, the job is broken down into smaller tasks, classi- 
fied as easy, medium or hard depending on interactions with 
other tasks. The man-months for each method is given by the 
deliverable instructions divided by the productivity, and 
total man-months is the sum of man-months for each task. 
[Ref. 2: p. 106] 



Putnam Model 



Empirical observations by Aron provided the 
basis for the Putnam model. Norden found that research and 
development projects reflected overlapping phases and he 
indicated them by the Raleigh form. Norden found tha* the 
work cycles of the Raleigh form have the character istic of 
90 % of the work being done in two-thirds of the time with 
10% of the work taking one-third of the time at the end. 
This gives the reason for the long delays at the end of a 
project. Putnam found that software projects usually 
conform to Rayleigh- Nor den forms. "He related the system 
attributes, number of files, modules, and reports to the 
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manpower, understanding exactly what the software develop- 
ment process consists of over its life cycle, maintaining a 
data base that reflects the history of actual software 
development costs, and developing the most cost-effective 
allocation of resources to different phases of software.” 
[Ref. 2: p. 106] 

Putnam has developed Monte-Carlo simulation and 
linear programming to estimate development time and manpower 
from the trade-off law in the systems definition phase. 
"Other parameters that can be estimated are the contract 
milestones from computed development time, the impact of 
requirement changes during the development phase, optimal 
future resource allocation during the development phase, and 
computer usage and resource allocation during the operations 
and maintenance phase.” [Ref. 2; p. 106] The SLIM model, 
the updated version of the Putnam model, also has the abili- 
ties cf estimating computer costs and using the PERT sizing 
techniques. 

3. Dy na mic Transportable Models 

Models that use real time information and are 
portable to different environments are termed herein dynamic 
transportable models. These models can be evolved to 

reflect specific environmental influences. 

a. Meta Model 

The Meta model is an empirical model based 
primarily on the work of Boe-hm and Walston & Felix. This 
model permits the development of a resource estimation model 
for any particular organization. The model itself can be 
used from the beginning of the design phase through accept- 
ance testing and includes programming, management and 
support hours. Effort is expressed as some measure of size. 
Deviations from the average are explained by environmental 
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attributes known for each project. A background equation is 
computed, environmental factors analyzed and the model 
predicts effort for the project. A size measure is chosen 
from available dara. Estimating size for each project is 
accomplished by taking the total number of new lines written 
and adding them to 20^ of any old lines used in the project. 
A base-line relationship of lower standard error is derived. 
The size measure is called develooed lines. Developed 
modules is arrived at 
measured in man-months, 
folio ws : 

1. Compute rhe background equation 

2. Analyze one facncr available to explain the 
drfference between acnual effort and efrort as 
predicted by the background equation 

3. Use this model zo predict the effort for the new 
project. [Ref. 46: p. 108] 

A 

Ccl 2_ 'rC't. in Q d 2 .^ 3. nhB s nvincrrnsn't is cons s.s 

fol lows; 

1. Choosing a set of factors 

2. Grouping and compressing this data 

3. Isolating the important factors 

4. Incorporat ina the factors bv performing a 
multiple regression to predict the deviations of 
the points from the computed base-line. 
[Hef. U6: p. 111] 

As a rule of thumb, 10^ to 15% of the number of 
data points should be the number of environmental factors 
used to predict a given number of points. The Meta model 
collects data from a particular environment and uses that 
data to make predictions about the environment. 



in the same manner. Effort is 
The Meta model is employed as 
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Good managers can usually estimate the cost and 
effort of a software development project better than the 
predictions of a model brought in from another environment. 
The expectation is that this model will assist those 
managers in making even better predictions concerning cost 
and effort. The Meta model is developed by duplicating the 
basic steps of the model with information from a unique 
environment. The model is molded into the environment which 
will use it and not simply tuned to accommodate the new 
environment. The model itself is based or. earlier works by 
Walstcn & Felix and Boehm who attempted to relate project 
size to effort. Measures used to express size in the Meta 
model are: 

1. Lines of Source Code (LOSC) 

2. Executable Statements 

3. Machine Instructions 

u. Number of Modules 

base line equation is used in conjunction with 
individual attributes of a project that affect the base line 
equation. Boehm and Walston & Felix have suggested similar 
models. Environmental differences explain variations from 
the averaaes arrived at by various equations. Environmental 
differences are accounted for by a number of factors such 
as: 

1. Skill and experience cf the programming team 

2. Use of good programming practices 

3. Difficulty of the project (complexity) 

A two step approach is used to develop the 



moQsr . 

1 . 

2 . 



Effort exerted on an average project is expressed as 
a function of size. 

Deviations from the average are attributed to envi- 
ronmental characteristics. The background equation 
is derived from the relationship between effort and 
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Size 



The measurement 



cf size depends on 



available. 

The use of the model is as follows: 



the data 



1. Estimate size of new project 

2. Use base-line to get standard effort 

3. Estimate necessary factor values 

4. Compute difference this project should exhibin 

5. Apply than difference no standard effort. 

[ aef. 46: p. 114] 

The main difficulty with the Meta model involves 
identifying significant environmental factors and decidina 
how many to use in the estimating process. Tables III, IV 
and V include envir cn mental factors identified by Walston S 
Felix, Boehm and those identified at the Software 

Engineering Laboratory at the MASA/Gcddard Space Flight 
Center where Bailey and Basil! collected the data to demon- 
strate the Meta model. For any particular project, 

attributes selected for study depend on what information is 
available in the data base. 

Of the original 71 attributes that the 

researchers thought to have influence on the effort for a 
Meta project, 21 were selected for analysis and grouped into 
three major categories. Predicting a variable with a few 
data points (18) using many factors is not st a tis-ically 
sound. The problem with adding the points of each attribute 
that indicated its influence and using the sum for the 
influence of that category is that some individual factors 
that may be very influential lose their identity. Two ways 

around this are to use more data points and evaluate each 

attribute independently or to dexermine the relative affect 
of each attribute and weigh them independently. Bailey and 
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TABLE III 

Evaluation Factors - SEL 



Program design language (development and design) 

Formal design review 
Tree charts 
Design formalisms 
Design/decision nones 
Walk-through: design 

Walk-through : code 

Cods reading 
Top-down design 
Top-down code 

Structured code ( 

Librarian 

Chief Programmer Teams 
Formal Train ina 
Formal nest plans 
Unit development folders 
Formal documennation 

Heavy managemenn involvement and control 

Iterative enhancement 

Individual decisions 

Timely specs and no changes 

Team size 

On schedule 

ISO development 

Overall 

Reusable code 

Percent programmer effort i 

Percent management effort j 

Amount documentation I 

Staff size I 

fRef. 46: p. 112] i 

I 



Basili did not have the requisite criteria for either solu- 
tion so they used the described method of grouping. 

b. ?rice-S and Price-SL 

The Price-S and the Price-SL are empirical 
models developed by RCA and can be used in conjunction to 
estimate the software costs during a support period for a 
given project [Ref. 47: pp . 663-664 ]. The Price-S model 

uses a top down approach to determine the resources required 
in a software development project. The model delivers cost 
and schedule for size, type and difficulty of the subject 
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TABLE 17 



Evaluation Factors - Walston and Felix 



Customer experience 

Customer participation in definition 
Cusxomer interface complexity 
Development location 
Percent programmers in design 
Programmer qualifications 
Programmer experience with machine 
Programmer experience with language. 

eg r :i\ 9T 3 with applicl^ion 

Werxed together on same type' of oroblem 
Cusnomer originated program design changes 
Hardware under ievelopmenn 
Develccmenr environment closed 
Development environment open with requ-st 
Development environment open 
Deveiooment environment HJE 
Development environment TSO 
Percent code structured 
Percent code used code review 
Percent code used top-down 
Percent code by chier-pr ogrammer teams 
Complexity of application processing 
Complexity of nrogram flov 
Complexity of internal communication 
Comolcxitv of external c cmmunication 
Ccmolexitv of data-base structure 
Percent code non-math and I/O 
Percent code math and computational 
Percent code CPU and I/O control 
Percent code fallback, and recoverv 
Percent code other 

Proportion code real time of interactive 
Design constraints: main storage 

Design constraints: timing 

Design constraints: I/O capability 

(Jnclassi fied 
[Ref. 46: p. 112] 
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project. The ?rice-S model uses information from historical 
data bases to estimate the costs of a new project. The 
Price-S model gives information about the software when it 
is installed for operation. The Price-SL model uses infor- 
mation about the environment to estimate the cost to be 
incurred during a particular support period. Combining 
these two models, we arrive at cost estimates up *o a 
particular point in the development phase and throughout a 
given support period. 
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T4BL2 7 

Environmental Factors - Boehm 



Required fault freedom 

Daxa base size 

Product complexity 

Adaptation from existing software 

Execution time constraint 

Main storage constraint 

Virxual machine volatility 

Computer resnonse time 

Analyst capability 

Applications experience 

Prcarammer Capanility 

Virrual machine experience 

Proaremming language experience 

Mcaern programmrng practices 

Use of software tools 

Required development Schedule 

[Ref. 46: p. 112] 



The Prics-S model provides the fcllcving cost 

dri vers: 

1. Instructions 

2. Application 

3. Platform 

u. Development Schedule 

Software size is measured in the number of instructions. 
Application refers to the type of software being developed. 
Platform refers to the environment in which the software 
operates. Development schedule is self explanatory. A 
development schedule is computed and compared with a design 
schedule and the degree to which the design schedule is 
normal, accelerated or stretched out will affect the amount 
of repair activity. Accelerated schedules will be more 
costly and stretched out schedules will cost less due to the 
extra time to develop better quality software. 
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The ?rice-SL identifies two primary cost 

dri vers: 

1, Support Schedule (SSTAHT to SEND) 

2. Growth Factor 

Shorter schedules will see bugs more quickly found but a 
lower total number of bugs. Shorter schedules will preclude 
enhancements to the sysrem and the anticipated growth factor 
will probably be lower for short schedules. The number of 
installations and the amount of average usages will affecn 
the number of bugs found. The higher either of these, nhe 
more bugs. Other support economic parameters are modifiers 
of the calculated costs and include multipliers for support 
mark-ups and support escalation. 

Costs for the Price-SL are categorized as 

follows: 

1. Maintenance 

2. Enhancement 



3 . Q ro w "ih 
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in each cansgory: 



following five elements 



1. Systems Engineering: technical tasks of the entire 

software system such as updating test plans and test 
specifications . 

2. Programming: cost for implementing design and code 

chan ges. 

3. Configuration Control: cost of maintaining system 

integrity and determination of system baseline. 

4. Quality Assurance: cost of maintaining system 

integrity and determination of system baseline. 

5. Documentation: cost of all changes needed to support 

Maintenance, Enhancement and Growth. 

6. Program Management 

Costs on a yearly basis are provided for the three major 
areas or the five elements. The ?rice-S and the Price-SL 
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models are available from ECA and can be used to estimate 
cost in varying environments. 

C, COCOMO 

The constructive COst Model detailed by Boehm in 
his most recent: publication is a most powerful instrument 
for estimating cost and effort in software develcpmen- 
proiects. The more detail that is provided as input to a 
cost estimation model, the more accurate the estimates will 
probably be. The CCCOMC model allows the preparation of 
estimates in good detail and specifies and processes them 
with considerable efficiency. The following factors impact 
cost : 

1. Cost Driver: Product Attributes 

a) P.ELY: Required software reliability 

i) Does the software perform its intended func- 
tions over the next utilization and 

ft 

subsequent utilizations? 

ii) DATA: Data base size 





iii) 


CPLX: Software 


product complexity 


CO 


St Driver: Computer At 


tributes 


a) 


TIME: 


Execution time 


constraint 


b) 


STOE: 


Main storage constraint 


c) 


VIET: 


Virtual machine 


vola till t y 


d) 


TURN: 


Computer t urnar 


ound time 



3. Cost Driver; Personnel Attributes 





ACAP: 


An al 


yst 


ca 


pabi li 


ty 


b) 


PCAP: 


Prog 


rammer 


capab 


ility 


c) 


VEXP: 


Virt 


ual 


ma 


chine 


experience 


d) 


LEXP: 


Lang 


uag 


e e 


xper ie 


nee 


Cos 


;t Dri 


ver ; 


Pro 


jsc 


t Attr 


ibutes 


a) 


MODP: 


Use 


of 


mod 


ern pr 


ogramming practices 


b) 


TOOL: 


Use 


of 


sot 


tware 


tools 


c) 


SCSD; 


Deve 


lop 


men 


t schedule constraint 
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Hierarchical decomposition is used to aid in 
producing cost estimates. The lowest level is the module. 
Cost drivers that are described an this level are: 
complexity and adaptation from existing software: program- 

mer's capability level and experience with the language and 
virtual machine on which the software is to be built. The 
second level is the subsystem level. A number of cost 
drivers affect this level. The cost drivers vary from 



snh system “c subsystem but are usually th: 



same to: 



modules in the particular subsystem. The top level is the 
system level. This level is used to apply overall project 
relaticns like nominal effort and schedule equations and to 
apply the nominal project effort and schedule breakdowns by 
phase. 

For each cost driver, a set of tables is used to 
account for its affect cn each major development phase. 



4 . 



Overall .lodel Svalua-'^icn 



Boehm has enumerated a number 



n n r' T' 



V r. 1. u r. 



software cost estimating models can be evaluated. 

1. Definition: do we understand from the model what 

costs it is estimating and what costs it is 

excl udinq? 

2. Fidelity: do estimated costs compare favorably with 

actual costs? 

3. Objectivity: are cost drivers related to factors 

that are objectively measurable and not open to mani- 
pulation to get what we want? 

4. Constructiveness: is it clear from the model why a 

particular estimate is arrived at and is the software 
project more underst andable because of the model? 

5. Detail: does the model sufficiently breakdown the 

project for estimation purposes? 
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. Stability: do small input changes produce small 

output changes? 

7. Scope; is the model applicable to the type of 
project needed to be estimated? 

3. Ease of Use; are the inputs and options used by the 
model easy to understand and specify? 

9. Prospectiveness; does xhe model only use information 
nhat can be found before completion of the project? 
This criterion is used only for cost prediction. 

10. Parsimony: are redundant factors and factors that do 

not contribute to the result of the model avoided? 
[P.ef. 3: p, 4761 

We vfill examine the models presented with respect to 
the apoiicabili ty of a number of the above criteria. 

a. Definition 



The I33-FSD model, the 3ai lev-3asili mcd^l and 
the 1979 GHC model provide fairly thorough definitions of 
the incuts and outputs used. COCOMO provides as thorough as 
possible definition of the activities and quantities found 
in the model while not overly constraining either the 
model’s generality or a project's flexibility. [Hef. 3: p. 
521] The TRW (SCEP) model uses a standard work breakdown 
structure to define costs included and excluded in 
est imates. 



b. Fidelity 

COCOHO estimates come within 20% of the actual 
development figures for the projects in the COCOMO database 
70% of the time. This means a standard deviation of the 
residuals of roughly 20% of the actuals. [Ref. 3; p. 521] 
An analysis of the lEM-FSD model reported a standard devia- 
tion cf 1.7 1 [Ref. 48; p. 5 21]. The Bailey-Basili showed a 
standard deviation factor cf 1.15 for a fairly uniform set 
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TABLE 11 

Factors Used in Various Cost Models 



Group 



FflClV 



SDC. TPW. PMtr.. nCA. 80E1NQ. GPC. 

1965 1972 SUM Ooty PRICE S tSM 1977 1979 COCOMO 



Prooram 

attnOutM 



Cornputar 

attnbutM 



Panonnai 

attnbutaa 



Protmci 

annPutaa 



Sourca matnjctions 
Ob(«ct instrucDona 
Numoar ot rouortaa 
Nuntt)«f of data Hama 
NumPar of output formata 
Oocumamation 
Numbar of personnat 

Type 

Compfaiity 

Lan^uA^a 

Reuse 

Roquirod rulusOtiily 

Tifoe consuamt 
Storacja constraint 
rfardware configuration 
Concureoi KarcJware d aeafop m a n i 

Personnel caoabdify 
Personnat continutiy 
Hardware evpenence 
Aoplicaoons expenenc* 

Language expenenca 

Tools and tecfimooes 
Customer interlace 
Roquir aments definition 
Requirements vo'atilifV 
Scneduta 
Sacunfy 

Computer access 
Travel/ r utiosfing 
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fRef. 3: p. 511] 



of 13 prelects ar NASA/God 
fidelity of the CCCOHO mo 
costs of projects in the 
models' estimates of those 
database was used to calibr 
future projects haire yet 
goodness of the model's est 
The Putnam 197 



mates on small 
reasonably well. 



pro jects 
P utnam ' 



dard [Hef. 46: p. 115.]. The 

del with respect to the actual 
database is better than other 
costs. A large portion of the 
ate the model's parameters. No 
teen completed to evaluate the 
imates . 

8 model gives extreme overesti- 
and estimates large projects 
s more recently developed SLIM 



39 



model appears to have overcome this problem. [Ref. 49: p. 

196] The TEW (SCEP) model is still in an experimental stare 
and needs more comparisons of SCS? estimates with actual 
proiect results [Ref. 49: p. 198]. 

c. Obj.ectivity 

The SLIM and the ?rice-S models have made some 
progress in expanding a single complexity factor into a 
number of constituent elements [Ref. 3: p, 522]. The orig- 
inal Price-S model was extremely sensitive to the subjective 
ccmDlexity factor [Ref. 49: p. 1981. The COCOMO model has 
tried to make the complexity factor more objective in a 
number of ways. Complexity has been made a module level 
instead of a subsystem or system level rating. Sources of 
oroductivity have been separated from the complexity cost 
drivers as much as possible and made into separate cost 
d rf- A cr for —d ch corriplsxi^v rddinc hds 

developed. The TEW (SCS?) model includes a complexity 
factor. The complexity rating is a charac'srist ic of each 
unit in the software, and a complexity scale is available to 
provide a unique complexity rating for each type of unit. 

d. Construct ivenes s 

The COCOMO mode 1 provides a detailed listing of 
the factors affecting the cost of a project. It estimates 
the impact of an individual factor. The model provides 
increased understanding of the software lifecycle for the 
project. [Ref. 3: p. 522] The TEW (SCS?) mcdsi provides a 
scale to indicate the degree of impact of factors on pro-iect 
activities. 
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e. Detail 

Models requiring mors detail usually produce 
gore accurate estimatsSS. 



1. The gathering ojf greater detail tends to increase 
peopxs's understanding of the job to be done; and 

2. if the added detail results in the overall esti- 
mate being the sum or some smaller inaividual 
estimates, the law of large numbers tends to work 
to decrease the variance of the es-imate. 
fHef. 49: p, 200] 



COCOMO is a hierarchy of models with the Basic 
COCOMC being used for early estimates and the Intermediate 
and Detailed COCOMO *s being used for more detailed and accu- 
rate estimates. The TRW- Wolverton model is an effective 
micro model and provides detail in phase and activity break- 
downs. The 1979 G3C model also provides detail in phase and 
activity breakdowns. [Ref. 3: p. 522] 



f. Stability 



The Doty model has discontinuities at the neigh- 
borhood of 10,000 source instructions. Small differences in 
sizing can lead to large differences in cost in this area. 
£Ref, 50] Most cost estimating models, CCCOMO included, 
avoid this problem by providing a number of rating levels 
for cost driver attributes and allowing interpolation 
between them. 



g. Scope 

The IBM-FSD model, the Meta model, the ?rice-3L 
and the COCOMO models have all been developed to meet a wide 
variety of projects and applications. Algorithmic cost 
models in general have a difficult time in general in esti- 
mating cost for projects under 2000 DSI. [Sef. 3: p. 523] 
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Ease of Use 



SLI21 and Price- S are well 
use and understanding. CCCOMO hie 
them easy zo use and to understand. 

The TRW (SC EP) model 
projects less than five person years 
functions well for projects over 



engineered for ease of 
rarchy of models makes 
[Ref. 3: p. 523] 
overestimares costs on 
in total efforr, but it 
the range of 60-2000 



man months. 



Pro spec* iveness 



Most current cost models including COCOdO use 
parameters rhat can be ssrimated rather well at rhe begin- 
ning of a projecr. The only exception for COCOMC is -he 
difficulry with sizing “he project. 



j. Parsimony 



The Walsr on- Pel ix model uses different enrries 
for modern programmina pracricss where one would be alrighr 
fcr practical esrimaticn of projccns. [Ref. 48] The CCC0!10 
model makes efforrs to only use factors rhar have a consid- 
erable affecr on software prod ucnivity . The model can be 
raijlored zo a particular environment to eliminare redundancy 
in facrcrs. [Ref. 3: p. 524] 



B. ESTIMATING COST AND EFFORT: CRITICAL FACTORS 

1 • Pi s cuss ion 

We conclude tha* what is needed in the field of 
esnimatinq cosr and effort in software development projects 
is a reliable, dynamic, transportable model that is easy to 
use. It appears intuitively obvious to us that cost, effort 
and time can be saved by adopting an already existing cost 
and effort estimating model to a new environment rather than 
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genera-inq an entirely new model from the ground up. The 
model should be able to estimate cost and effort throughout 
the lifecycle of a software projec*. Most models now only 
estimate through the completion of testing and the beginning 
of operation giving little or no attention to the 
maintenance phase. The maintenance phase of a software 
lifecycle currently consumes rhe major portion of resources 
expended upon a software development effort [3ef. 34: p. 

Vll 1 ], 

Any measure of effort should be linked to the 
successful completion of the functions of a project. The 

preliminary work, on a particular design decision may be well 
understood by software developers . The basic steps may 
account for a major physical portion of the effort. The 

concluding work done to implement a design decision and the 
integratinq of numerous design decisions/modules to meke the 
system operational often commands the greatest effort. The 
model should measure effort in the number of lines of source 
code (LOSC) produced but should also relate this figure to 
the area of applicability of the lines. To reiterate, LOSC 
produced at the beginning of the development of a design 
decision may be far easier tc produce than those at the end 
of the effort. 

Statistical investigation should be used to estab- 
lish relationships which make it possible tc predict cost 
and effort in terms of other variables. Regression tech- 
niques are used to perform this task. Since the number of 
variables affecting the cost and effort estimated for a 
given project will be many, multiple regression analysis 
will be necessary. In using observed data to formulate a 
mathematical equation to predict desired values from given 
values (a procedure known as curve fitting), three problems 
arise : 

1, the kind of equation tc be used must be decided 



93 



2. the be ST of this type must be found 

3. the goodness of fin of the eg-uaxion mus- be 
determined. 

[Ref. 51: pp. 431-433] 

The equation usually chosen results from the inspec- 
tion of the data in most instances, but the most objective 
menhcds for deciding on what curve to fit to numerous points 
should be used. Differences in projecn estimations will be 
explained in accordance with environmental variations. The 
key to esr imaring cost and effcrr in a software development 
project is xo isclaxe xhose elements that cause prcjec” 
esximaxes xo differ from expected values. Cr.ce these 
elements are identified, they can be accounted for in the 
estimation process and extremely accurate estimates can be 
ach ie ved . 

C. SOMKARY 

We have endeavored to present a number of environmental 
factors influencing software development projects, and the 
methods now in use to predict cos-t and effort for those 
projects. From our study of the literature in the area of 
software development and from an analysis of various models, 
we have tried to assimilate those problems that should be 
addressed in the development of a dynamic, transportable, 
prediction model. We also endeavored to alert the novice to 
and refresh the experienced reader with the problems he may 
expect to encounter with software cost and effort estimation 
models. As it is probably painfully apparent to the reader 
at this point, models are often complex and difficult to 
understand. We recommend to the average manager that he 
familiarize himself with the information presented in the 
research and then go and hire someone who is technically 
competent for specific guidance. If it is of any 
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compensation to the reader, the authors of this research 
have had as difficult a time as he or she may have had in 
understanding the models presented. 

The key to the success of any such model is the ability 
of the estimators to identify variables in the environment 
affecting the estimations and account for these variables in 
the mathematical equation predicting cost and effort. The 
weaknesses with current estimating procedures are sixfold: 

1. estimating size 

2. determining environmental influences 

3. determining complexity 

4. understanding the models themselves 

5. lack of attention to the experience of the developers 

6. lack of attention tc the management effort and the 
project manager. 

k hopeful avenue of research that may provide more reli- 
able estimates is Silver's method of using structural 
decomposition of requirements and design parameters. >;hat 
is missing or under emphasized in most proposals for esti- 
mating cost and effort in software development projects in 
private industry is consideration of the management effort 
and the project manager. Unless a sound team is organized 
under a strong leader, all estimations of project cost and 
effort will prove to be under estimates. 

D. THE EUTDRE OF SOFTBARE DEVSLOPHENT PROJECTS 

Ss^imating cost, and effort, in software develcprent 
projects has already been influenced by the introduction of 
various tools and the concept cf software development envi- 
ronments. Programmer productivity is expected tc increase 
as tods are refined and better integrated with one another. 
What is especially exciting in the long term future of 
programming, that is, programming into the early decades of 
the 21st century, is the concept of automatic programming. 
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Th 9 tera 'aatomatic programming' has been used for many 
years to refer to the process by which an executable 
program may be produced from nonprocedural 
specifications of the task to be oerformed. Over the 
Icnaer term, it will be possible for programmers to 
create running pregrams by providing a speci f ication of 
program functions and outputs, without having to“proceed 
with a detailed program design or with the produc.ion of 
code. rsef. 52: p. 204] 



The present differences between application programmers 
and system programmers are likely to increase. System 
programmers deal with the details of ~he low level computer 
whereas application programmers deal with the development of 
proarams to meet user specifications. With the anticipated 
advent of automatic programming, the user-operator will 
carry out what we now consider programming as he interacts 
using natural language with the computer. The application 
programmer will increasingly be involved with understanding 
the needs of particular application areas for software, 
i.e., medical and information system applications, their 
infermation requirements, organizational snruc'ures and 
their personnel makeup. He will assist the ussr-opercters 
of the companies in understanding their needs and converting 
these needs into specific requests to be automatically 
programmed by the computer into an affective application 
software program. 

...it can be seen that the nature of programmina and 
programmers is certain to change, and that an increasing 
share of what we now term programming will be carried out by 
user-operators, who will have tools' at their disposal that 
permit them to interact naturally with a computer system and 
specify their requests. It is only when' such tools are 
provided that the exponential growth in the number of 
programmers and the cost of software can be slewed and that 
attention may be devoted to making the greatest possible 
beneficial use of the computer. [Ref. 52: 'p. 205] 
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